Administracja sieci komputerowych - W2: DHCP - Dynamic Host Configuration Protocol

Cel slajdu: Slajd omawia zagadnienie „DHCP: Zasada działania, konfiguracja i DHCP Relay” w kontekście: Automatyzacja konfiguracji parametrów sieciowych w warstwie 3.

Automatyzacja konfiguracji parametrów sieciowych w warstwie 3

Wykład poświęcony jest protokołowi dynamicznego konfigurowania węzłów – DHCP (Dynamic Host Configuration Protocol), zdefiniowanemu w standardzie RFC 2131. Omawiamy ewolucję mechanizmów przydziału parametrów sieciowych od protokołu RARP (RFC 903) i BOOTP (RFC 951), szczegółową mechanikę czterofazowej negocjacji DORA (Discover, Offer, Request, Acknowledge), strukturę nagłówka binarnego oraz rolę opcji DHCP (RFC 2132). Przedstawiamy zasady wdrażania serwera w środowisku Linux i RouterOS, zagadnienie rezerwacji statycznych, funkcjonowanie agenta przekazywania (DHCP Relay) w sieciach wielosegmentowych oraz zaawansowane mechanizmy ochrony w warstwie 2, w tym DHCP Snooping.

DHCP: Zasada działania, konfiguracja i DHCP Relay: Slajd przedstawia zagadnienie Automatyzacja konfiguracji parametrów sieciowych w warstwie 3 w ramach tematu DHCP: Zasada działania, konfiguracja i DHCP Relay na przykładach poleceń oraz diagnostyki w systemach Linux, Windows i RouterOS. Szczegóły formatu komunikatów i opcji opisano w RFC 2131 i RFC 2132, a implementacje serwerowe dostarczają między innymi ISC DHCP i Kea.

Cel slajdu: Slajd przedstawia kolejność omawianych zagadnień i wskazuje miejsce bieżącego tematu w strukturze wykładu.

Plan zagadnień teoretycznych i ćwiczeń laboratoryjnych

Rola i fundamenty protokołu DHCP w nowoczesnej infrastrukturze sieciowej
Szczegółowa analiza sekwencji DORA (DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, DHCPACK)
Struktura binarna nagłówka pakietu DHCP/BOOTP i rola asymetrii portów UDP 67 / UDP 68
Dylemat adresowania: od rozgłoszenia (Broadcast) do transmisji jednostkowej (Unicast)
Cykl życia dzierżawy: analiza timerów T1 (Renewal), T2 (Rebinding) oraz procedury APIPA
Wdrożenie serwera w systemie Linux: porównanie ISC DHCP Server i Kea DHCP, anatomia dhcpd.conf
Zarządzanie pulami dynamicznymi oraz rezerwacje statyczne adresów (Fixed Leases)
Architektura DHCP Relay: pokonywanie barier routerów L3, pole giaddr oraz Opcja 82
Ćwiczenia laboratoryjne: analiza bazy dhcpd.leases, inspekcja logów i zaawansowany sniffing w tcpdump
Zagrożenia bezpieczeństwa i ochrona: ataki Rogue DHCP, Starvation oraz mechanizm DHCP Snooping

Szczegółowa agenda wykładu: Slajd przedstawia zagadnienie Plan zagadnień teoretycznych i ćwiczeń laboratoryjnych w ramach tematu Szczegółowa agenda wykładu na przykładach konfiguracji i diagnostyki w systemie Linux. Szczegóły formatu komunikatów i opcji opisano w RFC 2131 i RFC 2132, a implementacje serwerowe dostarczają między innymi ISC DHCP i Kea.

Cel slajdu: Slajd określa wymagane efekty uczenia się, czyli wiedzę i umiejętności, które uczestnik opanuje po zajęciach i laboratorium.

Wymagania i efekty uczenia się

Zrozumienie mechaniki protokołu DHCP na poziomie analizy pól nagłówka i transakcji XID
Opanowanie sekwencji pozyskiwania, odnawiania i zwalniania dzierżawy IP w środowiskach wielosystemowych
Nabycie umiejętności bezbłędnej konfiguracji serwera DHCP (podsieci, bramy, DNS, pule adresów i wyłączenia)
Projektowanie i wdrażanie rezerwacji statycznych na podstawie adresu MAC oraz identyfikatora klienta (opcja 61)
Konfiguracja agentów przekazywania (DHCP Relay / IP Helper) na urządzeniach trasujących L3
Biegła diagnostyka nieprawidłowości za pomocą analizatora tcpdump, logów systemowych oraz narzędzi klienckich
Wdrożenie mechanizmów obronnych w warstwie 2 przełączników w celu eliminacji nieautoryzowanych serwerów DHCP

Główny cel techniczny i edukacyjny: Slajd przedstawia zagadnienie Wymagania i efekty uczenia się w ramach tematu Główny cel techniczny i edukacyjny na przykładach konfiguracji i diagnostyki w systemie Linux. Szczegóły formatu komunikatów i opcji opisano w RFC 2131 i RFC 2132, a implementacje serwerowe dostarczają między innymi ISC DHCP i Kea.

Cel slajdu: Slajd omawia zagadnienie „Rola systemu DHCP w infrastrukturze IT” w kontekście: Zarządzanie adresacją i konfiguracją węzłów sieciowych.

Zarządzanie adresacją i konfiguracją węzłów sieciowych

Centralizacja zarządzania: pojedynczy punkt kontroli nad całą przestrzenią adresową podsieci LAN
Eliminacja błędów ludzkich: wykluczenie przypadkowego skonfigurowania zduplikowanego adresu IP przez użytkowników
Efektywne gospodarowanie adresami: dynamiczny recykling adresów IP – stacje nieaktywne zwracają adresy do wspólnej puli
Dystrybucja kompleksowej konfiguracji: przekazywanie nie tylko adresu IP, ale również:
- Maska podsieci (Subnet Mask – Opcja 1)
- Brama domyślna (Router – Opcja 3)
- Serwery nazw (Domain Name Server – Opcja 6)
- Domena wyszukiwania (Domain Name – Opcja 15)
- Serwery czasu NTP (Network Time Protocol – Opcja 42)
- Maksymalna jednostka transmisji (Interface MTU – Opcja 26)
Wsparcie dla mobilności: bezproblemowe przełączanie urządzeń przenośnych między różnymi segmentami i sieciami Wi-Fi

Rola systemu DHCP w infrastrukturze IT: Slajd przedstawia zagadnienie Zarządzanie adresacją i konfiguracją węzłów sieciowych w ramach tematu Rola systemu DHCP w infrastrukturze IT na przykładach konfiguracji i diagnostyki w systemie Linux. Szczegóły formatu komunikatów i opcji opisano w RFC 2131 i RFC 2132, a implementacje serwerowe dostarczają między innymi ISC DHCP i Kea.

Cel slajdu: Slajd omawia zagadnienie „DORA: Krok 1 – Discover (Odkrywanie)” w kontekście: Inicjalizacja procedury pozyskiwania adresu (DHCPDISCOVER).

Inicjalizacja procedury pozyskiwania adresu (DHCPDISCOVER)

Stacja kliencka nie posiada przypisanego adresu IP ani wiedzy o topologii podsieci
Klient generuje i rozsyła komunikat DHCPDISCOVER w celu zlokalizowania dostępnych serwerów DHCP
Parametry adresowe pakietu:
- Adres źródłowy IP: 0.0.0.0 (brak własnego adresu IP)
- Adres docelowy IP: 255.255.255.255 (Limited Broadcast – rozgłoszenie lokalne)
- Port źródłowy UDP: 68 (DHCP Client), port docelowy UDP: 67 (DHCP Server)
- Adres źródłowy MAC: unikalny adres fizyczny karty klienta
- Adres docelowy MAC: FF:FF:FF:FF:FF:FF (Broadcast w warstwie łącza danych)
W nagłówku BOOTP/DHCP klient losuje 32-bitowy identyfikator transakcji: XID (Transaction ID)
Pole chaddr (Client Hardware Address) zostaje wypełnione adresem MAC stacji pytającej

DORA: Krok 1 – Discover (Odkrywanie): Krok 1 – Discover (ang. Odkrywanie): Slajd przedstawia zagadnienie Inicjalizacja procedury pozyskiwania adresu (DHCPDISCOVER) w ramach tematu DORA: Krok 1 – Discover (Odkrywanie) na przykładach konfiguracji i diagnostyki w systemie Linux. Szczegóły formatu komunikatów i opcji opisano w RFC 2131 i RFC 2132, a implementacje serwerowe dostarczają między innymi ISC DHCP i Kea.

Cel slajdu: Slajd omawia zagadnienie „DORA: Krok 2 – Offer (Oferta)” w kontekście: Propozycja parametrów dzierżawy ze strony serwera (DHCPOFFER).

Propozycja parametrów dzierżawy ze strony serwera (DHCPOFFER)

Każdy serwer DHCP, który odebrał komunikat DHCPDISCOVER i dysponuje wolnymi zasobami, przygotowuje ofertę
Serwer wstępnie rezerwuje wolny adres IP ze skonfigurowanej puli dynamicznej
Wysyłana jest odpowiedź DHCPOFFER zawierająca proponowaną konfigurację:
- yiaddr (Your IP Address): proponowany dla klienta adres IPv4
- siaddr (Next Server IP Address): adres serwera obsługującego kolejną fazę (np. serwer TFTP/PXE)
- Identyfikator transakcji XID: dokładnie taki sam, jaki klient przysłał w DHCPDISCOVER
- Opcja 51 (IP Address Lease Time): proponowany czas trwania umowy dzierżawy
- Opcja 54 (Server Identifier): adres IPv4 serwera składającego ofertę
- Opcje sieciowe: maska podsieci (Opcja 1), brama domyślna (Opcja 3), serwery DNS (Opcja 6)
Tryb wysyłki: zależny od flagi Broadcast Flag (zazwyczaj Broadcast lub bezpośredni Unicast L2)

DORA: Krok 2 – Offer (Oferta): Krok 2 – Offer (ang. Oferta): Slajd przedstawia zagadnienie Propozycja parametrów dzierżawy ze strony serwera (DHCPOFFER) w ramach tematu DORA: Krok 2 – Offer (Oferta) na przykładach konfiguracji i diagnostyki w systemie Linux. Szczegóły formatu komunikatów i opcji opisano w RFC 2131 i RFC 2132, a implementacje serwerowe dostarczają między innymi ISC DHCP i Kea.

Cel slajdu: Slajd omawia zagadnienie „DORA: Krok 3 – Request (Żądanie)” w kontekście: Wybór oferty i oficjalne żądanie dzierżawy (DHCPREQUEST).

Wybór oferty i oficjalne żądanie dzierżawy (DHCPREQUEST)

Klient analizuje otrzymane oferty DHCPOFFER i dokonuje wyboru (zazwyczaj wybiera pierwszą poprawną ofertę)
Klient rozsyła komunikat DHCPREQUEST potwierdzający chęć dzierżawy wybranego adresu
Dlaczego komunikat jest wysyłany jako Broadcast (255.255.255.255)?
- Klient formalnie nadal nie ma prawa posługiwać się proponowanym adresem IP (umowa nie została zatwierdzona)
- Wszystkie serwery DHCP w segmencie muszą usłyszeć ten komunikat:
  - Wybrany serwer dowiaduje się, że jego oferta została zaakceptowana
  - Pozostałe serwery dowiadują się, że ich oferty zostały odrzucone i natychmiast zwalniają tymczasowo zarezerwowane adresy IP
Kluczowe opcje w pakiecie DHCPREQUEST:
- Opcja 50 (Requested IP Address): adres IP wybrany z oferty DHCPOFFER
- Opcja 54 (Server Identifier): adres serwera, którego ofertę zaakceptowano

DORA: Krok 3 – Request (Żądanie): Krok 3 – Request (ang. Żądanie): Slajd przedstawia zagadnienie Wybór oferty i oficjalne żądanie dzierżawy (DHCPREQUEST) w ramach tematu DORA: Krok 3 – Request (Żądanie) na przykładach konfiguracji i diagnostyki w systemie Linux. Szczegóły formatu komunikatów i opcji opisano w RFC 2131 i RFC 2132, a implementacje serwerowe dostarczają między innymi ISC DHCP i Kea.

Cel slajdu: Slajd omawia zagadnienie „DORA: Krok 4 – Acknowledge (Potwierdzenie)” w kontekście: Ostateczne zatwierdzenie dzierżawy (DHCPACK lub DHCPNAK).

Ostateczne zatwierdzenie dzierżawy (DHCPACK lub DHCPNAK)

Serwer wybrany przez klienta weryfikuje dostępność adresu i odsyła ostateczne potwierdzenie: DHCPACK
Pakiet DHCPACK zawiera finalną, obowiązującą konfigurację:
- Zatwierdzony adres IP (pole yiaddr) oraz czas trwania dzierżawy (Lease Time)
- Definicję timerów odnawiania: T1 (Renewal) oraz T2 (Rebinding)
- Pełny zestaw opcji sieciowych (brama domyślna, adresy DNS, maska podsieci, domena)
Wejście w stan związany (BOUND):
- Klient konfiguruje interfejs sieciowy otrzymanymi parametrami
- Przed rozpoczęciem nadawania stacja przeprowadza test kolizji ARP Probe (RFC 5227)
Scenariusz negatywny – DHCPNAK (Negative Acknowledgment):
- Wysyłany, gdy serwer nie może przydzielić adresu (np. adres został w międzyczasie zajęty lub stacja żąda podsieci niezgodnej z topologią)
- Klient po odebraniu DHCPNAK bezwzględnie porzuca konfigurację i natychmiast wznawia proces od kroku Discover

DORA: Krok 4 – Acknowledge (Potwierdzenie): Krok 4 – Acknowledge (ang. Potwierdzenie): Slajd przedstawia zagadnienie Ostateczne zatwierdzenie dzierżawy (DHCPACK lub DHCPNAK) w ramach tematu DORA: Krok 4 – Acknowledge (Potwierdzenie) na przykładach konfiguracji i diagnostyki w systemie Linux. Szczegóły formatu komunikatów i opcji opisano w RFC 2131 i RFC 2132, a implementacje serwerowe dostarczają między innymi ISC DHCP i Kea.

Cel slajdu: Slajd omawia zagadnienie „Analiza ramek sieciowych w komunikacji DHCP” w kontekście: Struktura binarna nagłówka pakietu BOOTP / DHCP (RFC 2131).

Struktura binarna nagłówka pakietu BOOTP / DHCP (RFC 2131)

Pakiet DHCP jest bezpośrednim rozszerzeniem formatu nagłówka BOOTP (RFC 951)
Kluczowe pola nagłówka binarnego:
- op (1B): kod operacji – 1 = BootRequest (klient), 2 = BootReply (serwer)
- htype / hlen (1B + 1B): typ i długość adresu sprzętowego (dla Ethernetu: 1 oraz 6)
- hops (1B): licznik przeskoków przez agentów relay (początkowo 0)
- xid (4B): identyfikator transakcji łączący zapytania z odpowiedziami
- secs (2B): liczba sekund, jakie upłynęły od rozpoczęcia procedury przez klienta
- flags (2B): flaga Broadcast Flag (najstarszy bit: 0 = Unicast, 1 = Broadcast)
- ciaddr (4B): Client IP Address (adres klienta w stanach RENEW / REBIND)
- yiaddr (4B): Your IP Address (adres przydzielany klientowi przez serwer)
- siaddr (4B): Next Server IP Address (adres serwera kolejnego etapu, np. PXE TFTP)
- giaddr (4B): Gateway IP Address (adres IP przekaźnika DHCP Relay)
- chaddr (16B): Client Hardware Address (adres fizyczny MAC stacji klienta)
- sname (64B) / file (128B): nazwa serwera oraz nazwa pliku rozruchowego (PXE/TFTP)
- options (zmienna długość): pole opcji z nagłówkiem Magic Cookie: 0x63825363

Analiza ramek sieciowych w komunikacji DHCP: Slajd przedstawia zagadnienie Struktura binarna nagłówka pakietu BOOTP / DHCP (RFC 2131) w ramach tematu Analiza ramek sieciowych w komunikacji DHCP na przykładach konfiguracji i diagnostyki w systemie Linux. Szczegóły formatu komunikatów i opcji opisano w RFC 2131 i RFC 2132, a implementacje serwerowe dostarczają między innymi ISC DHCP i Kea.

Cel slajdu: Slajd omawia zagadnienie „Standardowe porty komunikacyjne: UDP 67 i UDP 68” w kontekście: Architektura asymetrii portów warstwy transportowej.

Architektura asymetrii portów warstwy transportowej

Numery portów zarejestrowane oficjalnie przez organizację IANA:
- UDP 67: bootps (Bootstrap Protocol Server) – port nasłuchu Serwera DHCP
- UDP 68: bootpc (Bootstrap Protocol Client) – port nasłuchu Klienta DHCP
Dlaczego protokół DHCP wykorzystuje dwa różne porty transportowe?
- W tradycyjnych protokołach klient wysyła zapytanie z losowego portu efemerycznego (np. >1024), a serwer odpowiada na ten port
- W początkowej fazie DHCP stacja nie posiada skonfigurowanego stosu IP ani własnego portu
- Gdyby serwer rozsyłał odpowiedzi broadcastowe na port 67, wszystkie inne serwery DHCP w segmencie odbierałyby te pakiety, traktując je błędnie jako zapytania klientów (ryzyko pętli komunikatów)
- Rozdzielenie ról: stacje klienckie nasłuchują wyłącznie na porcie 68, a demony serwerowe wyłącznie na porcie 67
Współczesne reguły zapór sieciowych (iptables/nftables) muszą uwzględniać ruch dwukierunkowy na obu tych portach

Standardowe porty komunikacyjne: UDP 67 i UDP 68: UDP 67 i UDP 68: Slajd przedstawia zagadnienie Architektura asymetrii portów warstwy transportowej w ramach tematu Standardowe porty komunikacyjne: UDP 67 i UDP 68 na przykładach konfiguracji i diagnostyki w systemie Linux. Szczegóły formatu komunikatów i opcji opisano w RFC 2131 i RFC 2132, a implementacje serwerowe dostarczają między innymi ISC DHCP i Kea.

Cel slajdu: Slajd omawia zagadnienie „Dylemat adresowania: L2 Broadcast a L3 Unicast” w kontekście: Mechanizmy transmisji pakietów w początkowej fazie negocjacji.

Mechanizmy transmisji pakietów w początkowej fazie negocjacji

Stan wyjściowy klienta: brak skonfigurowanego adresu IPv4, maski podsieci oraz adresu bramy domyślnej
Komunikacja początkowa wymaga użycia transmisji rozgłoszeniowej w obu warstwach stosu:
- Warstwa łącza danych (L2): adres docelowy MAC: FF:FF:FF:FF:FF:FF
- Warstwa sieciowa (L3): adres docelowy IPv4: 255.255.255.255 (Limited Broadcast)
- Adres źródłowy IPv4: 0.0.0.0 (zgodnie ze standardem RFC 1122)
Rola przełącznika L2: ramka rozgłoszeniowa jest powielana na wszystkie porty w obrębie danej domeny rozgłoszeniowej (VLAN-u)
Problem odpowiedzi serwera: w jaki sposób serwer ma przesłać odpowiedź DHCPOFFER do stacji, która formalnie nie posiada jeszcze adresu IP w L3? Rozwiązaniem jest bezpośredni Unicast L2 lub wykorzystanie flagi Broadcast Flag

Dylemat adresowania: L2 Broadcast a L3 Unicast: L2 Broadcast a L3 Unicast: Slajd przedstawia zagadnienie Mechanizmy transmisji pakietów w początkowej fazie negocjacji w ramach tematu Dylemat adresowania: L2 Broadcast a L3 Unicast na przykładach konfiguracji i diagnostyki w systemie Linux. Szczegóły formatu komunikatów i opcji opisano w RFC 2131 i RFC 2132, a implementacje serwerowe dostarczają między innymi ISC DHCP i Kea.

Cel slajdu: Slajd omawia zagadnienie „Od rozgłoszenia do transmisji jednostkowej: flaga Broadcast” w kontekście: Przejście od transmisji rozgłoszeniowej do komunikacji jednostkowej.

Przejście od transmisji rozgłoszeniowej do komunikacji jednostkowej

Flaga Broadcast Flag (pole flags w nagłówku BOOTP/DHCP):
- Najstarszy bit pola flags (16-bitowego): informacja od klienta o zdolnościach jego stosu sieciowego
- Wartość 1 (Broadcast): klient żąda, aby serwer przesyłał odpowiedzi DHCPOFFER i DHCPACK w trybie rozgłoszeniowym (używane przez systemy, których sterowniki odrzucają pakiety Unicast przed skonfigurowaniem adresu IP)
- Wartość 0 (Unicast): klient zezwala serwerowi na przesłanie odpowiedzi bezpośrednim Unicastem w warstwie 2 (na adres MAC zawarty w chaddr)
Komunikacja po zakończeniu cyklu DORA:
- Po zatwierdzeniu dzierżawy stacja wchodzi w stan związany (BOUND)
- Wszelka dalsza komunikacja z serwerem (odnawianie dzierżawy T1, zwalnianie adresu) odbywa się w standardowym trybie L3 Unicast → L2 Unicast, nie obciążając pozostałych węzłów w sieci

Od rozgłoszenia do transmisji jednostkowej: flaga Broadcast: Slajd przedstawia zagadnienie Przejście od transmisji rozgłoszeniowej do komunikacji jednostkowej w ramach tematu Od rozgłoszenia do transmisji jednostkowej: flaga Broadcast na przykładach poleceń oraz diagnostyki w systemach Linux, Windows i RouterOS. Szczegóły formatu komunikatów i opcji opisano w RFC 2131 i RFC 2132, a implementacje serwerowe dostarczają między innymi ISC DHCP i Kea.

Cel slajdu: Slajd omawia zagadnienie „Czas dzierżawy (Lease Time): dobór wartości” w kontekście: Optymalizacja parametru Lease Time w projektowaniu sieci.

Optymalizacja parametru Lease Time w projektowaniu sieci

Czas dzierżawy (Lease Time – Opcja 51 wg RFC 2132): okres, na jaki serwer DHCP udziela stacji prawa do posługiwania się przydzielonym adresem IPv4
Dzierżawa jest umową terminową – po jej upływie adres musi zostać odnowiony lub bezwzględnie zwrócony do puli
Zasady inżynierskiego doboru wartości Lease Time:
- Krótki czas dzierżawy (np. 1–4 godziny):
  - Zalecany w sieciach publicznych, gościnnych Wi-Fi, salach konferencyjnych i kawiarniach
  - Zaleta: szybki recykling adresów w ograniczonej puli (odchodzący użytkownicy szybko zwalniają zasoby)
  - Wada: zwiększony ruch kontrolny w sieci i częstsze odpytywanie serwera
- Długi czas dzierżawy (np. 7–30 dni):
  - Zalecany w sieciach korporacyjnych, biurach ze stałymi stacjami i infrastrukturze serwerowej
  - Zaleta: minimalne obciążenie łącza, stabilność adresacji, odporność na chwilowe awarie serwera DHCP

Czas dzierżawy (Lease Time): dobór wartości: Slajd przedstawia zagadnienie Optymalizacja parametru Lease Time w projektowaniu sieci w ramach tematu Czas dzierżawy (Lease Time): dobór wartości na przykładach konfiguracji i diagnostyki w systemie Linux. Szczegóły formatu komunikatów i opcji opisano w RFC 2131 i RFC 2132, a implementacje serwerowe dostarczają między innymi ISC DHCP i Kea.

Cel slajdu: Slajd omawia zagadnienie „Cykl życia: T1 (Renewal Timer)” w kontekście: Faza odnawiania dzierżawy (T1 = 50% Lease Time).

Faza odnawiania dzierżawy (T1 = 50% Lease Time)

Timer T1 (Renewal Timer): domyślnie wynosi dokładnie 50% całkowitego czasu dzierżawy (może być modyfikowany Opcją 58)
Przebieg procedury w stanie RENEWING:
- Po upływie czasu T1 stacja robocza podejmuje próbę przedłużenia umowy
- Klient wysyła pakiet DHCPREQUEST bezpośrednio do serwera, który udzielił dzierżawy
- Transmisja odbywa się w trybie Unicast L3/L2 (znany jest adres IP i MAC serwera z Opcji 54)
- W nagłówku pakietu pole ciaddr (Client IP) zawiera aktualnie posiadany adres IP stacji
Reakcja serwera:
- Jeśli podsieć jest nadal aktualna, serwer odsyła komunikat DHCPACK
- W pakiecie DHCPACK serwer przesyła nowy pełny czas Lease Time, co powoduje zresetowanie timerów T1 i T2
- Dla użytkownika i otwartych połączeń TCP proces ten jest w 100% przezroczysty (bez utraty pakietów)

Cykl życia: T1 (ang. Renewal Timer): T1 (ang. Renewal Timer): Slajd przedstawia zagadnienie Faza odnawiania dzierżawy (T1 = 50% Lease Time) w ramach tematu Cykl życia: T1 (Renewal Timer) na przykładach konfiguracji i diagnostyki w systemie Linux. Szczegóły formatu komunikatów i opcji opisano w RFC 2131 i RFC 2132, a implementacje serwerowe dostarczają między innymi ISC DHCP i Kea.

Cel slajdu: Slajd omawia zagadnienie „Cykl życia: T2 (Rebinding Timer)” w kontekście: Faza renegocjacji dzierżawy z dowolnym serwerem (T2 = 87.5% Lease Time).

Faza renegocjacji dzierżawy z dowolnym serwerem (T2 = 87.5% Lease Time)

Timer T2 (Rebinding Timer): domyślnie wynosi 87.5% (7/8) czasu dzierżawy (Opcja 59 wg RFC 2132)
Warunek wejścia w stan REBINDING:
- Klient od momentu osiągnięcia T1 wielokrotnie wysyłał zapytania Unicast do swojego serwera macierzystego, lecz nie otrzymał żadnej odpowiedzi (np. serwer uległ awarii, uszkodzeniu uległ zasilacz lub kabel)
Mechanika ratunkowa w stanie REBINDING:
- Klient zmienia tryb transmisji z Unicast na Broadcast L2/L3 (255.255.255.255)
- Klient wysyła komunikat DHCPREQUEST do wszystkich dostępnych serwerów DHCP w segmencie, pytając: „Mój serwer nie odpowiada – czy ktokolwiek inny może przedłużyć moją dzierżawę?”
Możliwe scenariusze odpowiedzi:
- Inny serwer uprawniony (np. zapasowy w klastrze Failover) odsyła DHCPACK i przejmuje obsługę dzierżawy
- Serwer posiadający inną konfigurację podsieci odsyła DHCPNAK, zmuszając stację do natychmiastowego pobrania nowej konfiguracji

Cykl życia: T2 (ang. Rebinding Timer): T2 (ang. Rebinding Timer): Slajd przedstawia zagadnienie Faza renegocjacji dzierżawy z dowolnym serwerem (T2 = 87.5% Lease Time) w ramach tematu Cykl życia: T2 (Rebinding Timer) na przykładach konfiguracji i diagnostyki w systemie Linux. Szczegóły formatu komunikatów i opcji opisano w RFC 2131 i RFC 2132, a implementacje serwerowe dostarczają między innymi ISC DHCP i Kea.

Cel slajdu: Slajd omawia zagadnienie „Wygaśnięcie dzierżawy i procedura APIPA” w kontekście: Procedura po wyczerpaniu czasu dzierżawy (Lease Expiration).

Procedura po wyczerpaniu czasu dzierżawy (Lease Expiration)

Osiągnięcie 100% Lease Time bez odpowiedzi:
- Klient bezwzględnie traci prawo do korzystania z dotychczasowego adresu IPv4
- System operacyjny ma obowiązek natychmiast usunąć adres IP z konfiguracji interfejsu sieciowego oraz skasować powiązaną trasę domyślną z tablicy routingu
- Wszystkie aktywne sesje TCP zostają natychmiast zerwane
Mechanizm APIPA (Automatic Private IP Addressing, RFC 3927):
- W przypadku braku odpowiedzi serwera DHCP stacja konfiguruje adres z puli 169.254.0.0/16
- Weryfikacja unikalności adresu za pomocą mechanizmu ARP Probe (RFC 5227)
- Konsekwencje dla stacji: stacja może komunikować się wyłącznie z innymi węzłami w tym samym segmencie L2; brak bramy domyślnej uniemożliwia dostęp do innych podsieci oraz Internetu
Równolegle w tle system nieustannie ponawia wysyłanie komunikatów DHCPDISCOVER w pętli ze zmiennym odstępem (exponential backoff)

Wygaśnięcie dzierżawy i procedura APIPA: Slajd przedstawia zagadnienie Procedura po wyczerpaniu czasu dzierżawy (Lease Expiration) w ramach tematu Wygaśnięcie dzierżawy i procedura APIPA na przykładach konfiguracji i diagnostyki w systemie Linux. Szczegóły formatu komunikatów i opcji opisano w RFC 2131 i RFC 2132, a implementacje serwerowe dostarczają między innymi ISC DHCP i Kea.

Cel slajdu: Slajd omawia zagadnienie „Proaktywne zwalnianie – mechanika DHCPRELEASE” w kontekście: Zwalnianie zasobów adresowych przez stację kliencką.

Zwalnianie zasobów adresowych przez stację kliencką

Cel operacji: natychmiastowe poinformowanie serwera DHCP o zakończeniu korzystania z przyznanego adresu IP przed upływem Lease Time
Tryb komunikacji: datagram DHCPRELEASE jest wysyłany bezpośrednio do serwera w trybie Unicast L3/L2 (na adres serwera z Opcji 54)
W nagłówku pakietu pole ciaddr zawiera zwalniany adres IP, a pole chaddr adres MAC stacji
Polecenia wywołujące procedurę w systemach:
- Linux (narzędzie dhclient): sudo dhclient -r eth0
- Windows (CMD / PowerShell): ipconfig /release
- MikroTik RouterOS: /ip dhcp-client release [find]
Reakcja serwera: serwer natychmiast zmienia stan rekordu dzierżawy na wolny, umożliwiając natychmiastowe przydzielenie tego adresu innemu zgłaszającemu się urządzeniu

Proaktywne zwalnianie – mechanika DHCPRELEASE: Slajd przedstawia zagadnienie Zwalnianie zasobów adresowych przez stację kliencką w ramach tematu Proaktywne zwalnianie – mechanika DHCPRELEASE na przykładach poleceń oraz diagnostyki w systemach Linux, Windows i RouterOS. Szczegóły formatu komunikatów i opcji opisano w RFC 2131 i RFC 2132, a implementacje serwerowe dostarczają między innymi ISC DHCP i Kea.

Cel slajdu: Slajd omawia zagadnienie „Szybki powrót do sieci – DORA w ujęciu skróconym” w kontekście: Procedura szybkiej renegocjacji dzierżawy (stan INIT-REBOOT).

Procedura szybkiej renegocjacji dzierżawy (stan INIT-REBOOT)

Stacja robocza, która została zrestartowana lub ponownie podłączona do sieci, posiada w pamięci nieulotnej zapisaną nieprzeterminowaną dzierżawę
Nie ma potrzeby przeprowadzania pełnego, czasochłonnego cyklu DORA (pominięcie faz Discover i Offer)
Przebieg procedury w stanie INIT-REBOOT:
- 1. Klient wysyła bezpośrednio komunikat DHCPREQUEST w trybie Broadcast
- 2. Pakiet zawiera Opcję 50 (Requested IP Address) z posiadanym dotychczas adresem IP
- 3. Pole ciaddr jest puste (0.0.0.0), ponieważ interfejs formalnie nie jest jeszcze podniesiony w L3
Decyzja serwera DHCP:
- Jeśli stacja znajduje się w tej samej podsieci, a rekord dzierżawy jest ważny → serwer odsyła natychmiastowy DHCPACK (czas negocjacji < 50 ms)
- Jeśli topologia uległa zmianie (inny VLAN) lub adres zajął ktoś inny → serwer odsyła DHCPNAK

Szybki powrót do sieci – DORA w ujęciu skróconym: Slajd przedstawia zagadnienie Procedura szybkiej renegocjacji dzierżawy (stan INIT-REBOOT) w ramach tematu Szybki powrót do sieci – DORA w ujęciu skróconym na przykładach konfiguracji i diagnostyki w systemie Linux. Szczegóły formatu komunikatów i opcji opisano w RFC 2131 i RFC 2132, a implementacje serwerowe dostarczają między innymi ISC DHCP i Kea.

Cel slajdu: Slajd omawia zagadnienie „Mobilność urządzeń i powiązane dylematy zmiany VLAN” w kontekście: Mechanizm detekcji niepoprawnej podsieci i komunikat DHCPNAK.

Mechanizm detekcji niepoprawnej podsieci i komunikat DHCPNAK

Scenariusz awaryjny: pracownik odłącza laptop od gniazdka w dziale marketingu (VLAN 10: 192.168.10.0/24) i przechodzi do sali konferencyjnej (VLAN 50: 192.168.50.0/24)
Laptop w stanie INIT-REBOOT wysyła pakiet DHCPREQUEST z żądaniem starego adresu: 192.168.10.45
Reakcja serwera DHCP obsługującego VLAN 50:
- Serwer analizuje podsieć interfejsu odbiorczego (lub pole giaddr przekaźnika)
- Stwierdza krytyczną niezgodność: żądany adres 192.168.10.45 nie należy do podsieci 192.168.50.0/24!
- Serwer bezwzględnie generuje komunikat DHCPNAK (Negative Acknowledgment)
Reakcja stacji roboczej:
- Klient natychmiast unieważnia stary adres, resetuje stan wewnętrzny do INIT i rozpoczyna pełny proces DORA od pakietu DHCPDISCOVER
- Wynik: stacja otrzymuje w kilka milisekund poprawny adres z nowego VLAN-u (np. 192.168.50.112)

Mobilność urządzeń i powiązane dylematy zmiany VLAN: Slajd przedstawia zagadnienie Mechanizm detekcji niepoprawnej podsieci i komunikat DHCPNAK w ramach tematu Mobilność urządzeń i powiązane dylematy zmiany VLAN na przykładach konfiguracji i diagnostyki w systemie Linux. Szczegóły formatu komunikatów i opcji opisano w RFC 2131 i RFC 2132, a implementacje serwerowe dostarczają między innymi ISC DHCP i Kea.

Cel slajdu: Slajd omawia zagadnienie „Konflikty zduplikowanych adresów w podsieci” w kontekście: Procedura DHCPDECLINE i badanie kolizji za pomocą ARP Probe.

Procedura DHCPDECLINE i badanie kolizji za pomocą ARP Probe

Przyczyna konfliktów IP: omyłkowe ręczne skonfigurowanie adresu ze strefy dynamicznej DHCP na stacji roboczej lub urządzeniu wdrożeniowym
Prewencja po stronie serwera (ICMP Ping Check):
- Profesjonalny serwer przed wysłaniem DHCPOFFER sonduje kandydujący adres pakietem ICMP Echo Request
- W przypadku nadejścia odpowiedzi serwer oznacza adres jako zajęty i wybiera inny
Weryfikacja po stronie klienta (ARP Probe wg RFC 5227):
- Po odebraniu DHCPACK stacja rozsyła zapytania ARP Probe (Sender IP = 0.0.0.0, Target IP = przydzielony adres)
- Jeśli inne urządzenie odpowie na zapytanie → wykryto konflikt adresów!
Wycofanie dzierżawy – komunikat DHCPDECLINE:
- Klient wysyła do serwera komunikat DHCPDECLINE odrzucający przydzielony adres
- Serwer DHCP natychmiast oznacza dany adres jako abandoned (porzucony/skonfliktowany) i wyłącza go z przydziału
- Klient powraca do stanu INIT i żąda nowego adresu IP

Konflikty zduplikowanych adresów w podsieci: Slajd przedstawia zagadnienie Procedura DHCPDECLINE i badanie kolizji za pomocą ARP Probe w ramach tematu Konflikty zduplikowanych adresów w podsieci na przykładach konfiguracji i diagnostyki w systemie Linux. Szczegóły formatu komunikatów i opcji opisano w RFC 2131 i RFC 2132, a implementacje serwerowe dostarczają między innymi ISC DHCP i Kea.

Cel slajdu: Slajd omawia zagadnienie „Architektura serwera w środowisku Linux” w kontekście: Zasada działania demona DHCP w przestrzeni użytkownika.

Zasada działania demona DHCP w przestrzeni użytkownika

Serwery DHCP w systemie Linux (np. dhcpd lub kea-dhcp4) działają jako procesy demona w przestrzeni użytkownika (user space)
Wyzwanie niskopoziomowe:
- Standardowe gniazdo sieciowe BSD (POSIX socket) wymaga istnienia skonfigurowanego interfejsu IP, aby odebrać pakiet
- Zapytanie DHCPDISCOVER przychodzi z adresu 0.0.0.0 i dociera jako rozgłoszenie L2/L3
- Jądro systemu w standardowym trybie mogłoby odrzucić taki pakiet z powodu braku trasy zwrotnej
Rozwiązanie inżynierskie:
- Demony DHCP wykorzystują gniazda surowe (Raw Sockets, w Linuksie mechanizm AF_PACKET z filtrem BPF), przechwytując ramki Ethernet bezpośrednio ze sterownika karty sieciowej przed stosem IP jądra
Po przetworzeniu pakietu demon przygotowuje odpowiedź i wstrzykuje ją bezpośrednio do interfejsu sieciowego w warstwie łącza danych

Architektura serwera w środowisku Linux: Slajd przedstawia zagadnienie Zasada działania demona DHCP w przestrzeni użytkownika w ramach tematu Architektura serwera w środowisku Linux na przykładach konfiguracji i diagnostyki w systemie Linux. Szczegóły formatu komunikatów i opcji opisano w RFC 2131 i RFC 2132, a implementacje serwerowe dostarczają między innymi ISC DHCP i Kea.

Cel slajdu: Slajd omawia zagadnienie „Oprogramowanie serwera: ISC DHCP Server vs Kea DHCP” w kontekście: Ewolucja systemów serwerowych Internet Systems Consortium (ISC).

Ewolucja systemów serwerowych Internet Systems Consortium (ISC)

Cecha architektoniczna	ISC DHCP Server (dhcpd)	ISC Kea DHCP (nowoczesny standard)
Status projektu	End-of-Life (ostatnie wydanie 4.4.3-P1 z października 2022 r.; ISC zaleca migrację do Kea)	Aktywny rozwój, oficjalny następca
Architektura silnika	Monolityczna (jeden wielki proces)	Modułowa (oddzielne daemony: DHCPv4, DHCPv6, DDNS)
Magazyn bazy dzierżaw	Plik tekstowy (`dhcpd.leases`)	Bazy danych SQL: PostgreSQL, MySQL, Cassandra
Zarządzanie i integracja	Edycja plików tekstowych	Pełne REST API przez protokół HTTP/JSON
Przeładowanie konfiguracji	Wymaga restartu usługi (chwilowy brak obsługi)	Dynamiczne przeładowanie w locie (zero-downtime)
Wysoka dostępność (HA)	Własny, skomplikowany protokół Failover	Wbudowane tryby: Load-Balancing, Hot-Standby

Oprogramowanie serwera: ISC DHCP Server vs Kea DHCP: ISC DHCP Server vs Kea DHCP: Slajd przedstawia zagadnienie Ewolucja systemów serwerowych Internet Systems Consortium (ISC) w ramach tematu Oprogramowanie serwera: ISC DHCP Server vs Kea DHCP na przykładach konfiguracji i diagnostyki w systemie Linux. Szczegóły formatu komunikatów i opcji opisano w RFC 2131 i RFC 2132, a implementacje serwerowe dostarczają między innymi ISC DHCP i Kea.

Cel slajdu: Slajd omawia zagadnienie „Instalacja usługi w systemach Debian / Ubuntu” w kontekście: Wdrożenie pakietu isc-dhcp-server i plik środowiskowy.

Wdrożenie pakietu isc-dhcp-server i plik środowiskowy

Instalacja pakietu w dystrybucjach opartych na systemie Debian:
```
$ sudo apt update && sudo apt install isc-dhcp-server
```
Konfiguracja interfejsu nasłuchu w pliku /etc/default/isc-dhcp-server:
- Zmienna INTERFACESv4: określa, na których interfejsach fizycznych demon ma przetwarzać ruch DHCPv4:
```
# /etc/default/isc-dhcp-server
INTERFACESv4="eth0"
INTERFACESv6=""
```
Zarządzanie usługą za pośrednictwem systemd:

$ sudo systemctl status isc-dhcp-server   # Sprawdzenie stanu demona
$ sudo systemctl restart isc-dhcp-server  # Restart po zmianie konfiguracji
$ sudo systemctl enable isc-dhcp-server   # Włączenie autostartu przy rozruchu

Instalacja usługi w systemach Debian / Ubuntu: Slajd przedstawia zagadnienie Wdrożenie pakietu isc-dhcp-server i plik środowiskowy w ramach tematu Instalacja usługi w systemach Debian / Ubuntu na przykładach konfiguracji i diagnostyki w systemie Linux. Szczegóły formatu komunikatów i opcji opisano w RFC 2131 i RFC 2132, a implementacje serwerowe dostarczają między innymi ISC DHCP i Kea.

Cel slajdu: Slajd omawia zagadnienie „Plik konfiguracyjny – anatomia dhcpd.conf” w kontekście: Struktura składniowa pliku /etc/dhcp/dhcpd.conf.

Struktura składniowa pliku /etc/dhcp/dhcpd.conf

Lokalizacja głównego pliku konfiguracyjnego: /etc/dhcp/dhcpd.conf
Podstawowe zasady składni:
- Każda deklaracja i dyrektywa musi być zakończona średnikiem (;) – brak średnika to najczęstszy powód awarii usługi!
- Komentarze rozpoczynają się od znaku krzyżyka (#)
- Wartości tekstowe i listy adresów ujmuje się w odpowiednie typy (np. łańcuchy w cudzysłowach)
Logiczna architektura pliku:
- Sekcja globalna: parametry domyślne stosowane do wszystkich podsieci (np. globalny Lease Time, domena wyszukiwania)
- Deklaracje zakresów (Scope declarations):
  - Bloki subnet ... netmask ... { ... } – konfiguracja podsieci i pul dynamicznych
  - Bloki host ... { ... } – konfiguracja rezerwacji statycznych
  - Bloki group { ... } – grupowanie wspólnych parametrów dla wybranych hostów

Plik konfiguracyjny – anatomia dhcpd.conf: Slajd przedstawia zagadnienie Struktura składniowa pliku /etc/dhcp/dhcpd.conf w ramach tematu Plik konfiguracyjny – anatomia dhcpd.conf na przykładach konfiguracji i diagnostyki w systemie Linux. Szczegóły formatu komunikatów i opcji opisano w RFC 2131 i RFC 2132, a implementacje serwerowe dostarczają między innymi ISC DHCP i Kea.

Cel slajdu: Slajd omawia zagadnienie „Deklaracja bloku podsieci (dyrektywa subnet)” w kontekście: Konfiguracja zakresu podsieci (subnet ... netmask ...).

Konfiguracja zakresu podsieci (subnet ... netmask ...)

Podstawowy blok logiczny definiujący parametry dla pojedynczej domeny rozgłoszeniowej L2:

subnet 192.168.1.0 netmask 255.255.255.0 {
    range 192.168.1.100 192.168.1.200;
    option routers 192.168.1.1;
    option domain-name-servers 192.168.1.1, 8.8.8.8;
    option domain-name "lab.local";
    default-lease-time 86400;   # 24 godziny (w sekundach)
    max-lease-time 172800;       # 48 godzin (w sekundach)
}

Kluczowa zasada inżynierska:
- Serwer DHCP musi posiadać deklarację subnet dla każdego fizycznego interfejsu sieciowego podłączonego do maszyny, nawet jeśli nie przydziela w nim adresów dynamicznych!
- W przypadku podsieci bez puli dynamicznej deklaruje się pusty blok:
```
subnet 10.0.0.0 netmask 255.255.255.0 { }  # Zapobiega błędowi startu serwera!
```

Deklaracja bloku podsieci (ang. dyrektywa subnet): Slajd przedstawia zagadnienie Konfiguracja zakresu podsieci (subnet ... netmask ...) w ramach tematu Deklaracja bloku podsieci (dyrektywa subnet) na przykładach konfiguracji i diagnostyki w systemie Linux. Szczegóły formatu komunikatów i opcji opisano w RFC 2131 i RFC 2132, a implementacje serwerowe dostarczają między innymi ISC DHCP i Kea.

Cel slajdu: Slajd omawia zagadnienie „Dynamiczne pule adresów (dyrektywa range)” w kontekście: Definiowanie puli adresów dynamicznych dla stacji roboczych.

Definiowanie puli adresów dynamicznych dla stacji roboczych

Dyrektywa range definiuje przedział adresów IPv4, z którego serwer dynamicznie przydziela adresy zgłaszającym się klientom:
```
range [adres_początkowy] [adres_końcowy];
```
W obrębie pojedynczego bloku subnet można zdefiniować wiele niezależnych zakresów, tworząc naturalne przerwy na adresację statyczną:

subnet 172.16.0.0 netmask 255.255.255.0 {
    # Pula 1 dla komputerów stacjonarnych:
    range 172.16.0.50 172.16.0.99;
    
    # Pula 2 dla urządzeń bezprzewodowych Wi-Fi:
    range 172.16.0.150 172.16.0.240;
    
    # Adresy 1-49, 100-149 oraz 241-254 pozostają wolne na urządzenia statyczne
    option routers 172.16.0.1;
}

Zasada działania: adresy są przydzielane sekwencyjnie lub w oparciu o stan bazy dzierżaw; po wyczerpaniu obu zakresów serwer odrzuca nowe zapytania do momentu zwolnienia zasobów

Dynamiczne pule adresów (ang. dyrektywa range): Slajd przedstawia zagadnienie Definiowanie puli adresów dynamicznych dla stacji roboczych w ramach tematu Dynamiczne pule adresów (dyrektywa range) na przykładach konfiguracji i diagnostyki w systemie Linux. Szczegóły formatu komunikatów i opcji opisano w RFC 2131 i RFC 2132, a implementacje serwerowe dostarczają między innymi ISC DHCP i Kea.

Cel slajdu: Slajd omawia zagadnienie „Parametr domyślnej bramy (option routers)” w kontekście: Dystrybucja trasy domyślnej dla stacji roboczych (Opcja 3).

Dystrybucja trasy domyślnej dla stacji roboczych (Opcja 3)

Opcja 3 protokołu DHCP (Routers Option wg RFC 2132):
- Przekazuje klientowi adres IPv4 routera wyjściowego (bramy domyślnej) dla danej podsieci
- Wartość ta jest wpisywana przez system klienta do lokalnej tablicy routingu jako wpis trasy domyślnej: 0.0.0.0/0 (default gateway)
Składnia w pliku konfiguracyjnym dhcpd.conf:
```
option routers 192.168.1.1;
```
Konfiguracja nadmiarowa (redundancja bramy):
- Standard dopuszcza podanie listy kilku adresów routerów oddzielonych przecinkami:
```
option routers 192.168.1.1, 192.168.1.2;
```
- W praktyce inżynierskiej zaleca się stosowanie protokołów redundancji bramy pierwszej linii (FHRP: HSRP, VRRP, CARP) i podawanie jednego adresu wirtualnego VIP (np. Virtual IP klastra VRRP)

Parametr domyślnej bramy (ang. option routers): Slajd przedstawia zagadnienie Dystrybucja trasy domyślnej dla stacji roboczych (Opcja 3) w ramach tematu Parametr domyślnej bramy (option routers) na przykładach poleceń oraz diagnostyki w systemach Linux, Windows i RouterOS. Szczegóły formatu komunikatów i opcji opisano w RFC 2131 i RFC 2132, a implementacje serwerowe dostarczają między innymi ISC DHCP i Kea.

Cel slajdu: Slajd omawia zagadnienie „Przekierowanie resolverów nazw (DNS Options)” w kontekście: Automatyczna dystrybucja konfiguracji DNS (Opcje 6 i 15).

Automatyczna dystrybucja konfiguracji DNS (Opcje 6 i 15)

Opcja 6: option domain-name-servers:
- Przekazuje listę adresów IPv4 serwerów DNS (Domain Name System), do których klient ma kierować zapytania o translację nazw domenowych
- Składnia:
```
option domain-name-servers 192.168.1.10, 1.1.1.1;
```
- Kolejność ma znaczenie: stacja odpytuje serwery sekwencyjnie w kolejności ich zdefiniowania
Opcja 15: option domain-name:
- Przekazuje domyślny sufiks domeny wyszukiwania (Search Domain) dla stacji:
```
option domain-name "corp.netstudio.pl";
```
- Ułatwienie dla użytkowników: wpisanie w przeglądarce nazwy intranet powoduje automatyczne dopełnienie do FQDN: intranet.corp.netstudio.pl
W systemie Linux parametry te trafiają do pliku /etc/resolv.conf lub demona systemd-resolved

Przekierowanie resolverów nazw (ang. DNS Options): Slajd przedstawia zagadnienie Automatyczna dystrybucja konfiguracji DNS (Opcje 6 i 15) w ramach tematu Przekierowanie resolverów nazw (DNS Options) na przykładach konfiguracji i diagnostyki w systemie Linux. Szczegóły formatu komunikatów i opcji opisano w RFC 2131 i RFC 2132, a implementacje serwerowe dostarczają między innymi ISC DHCP i Kea.

Cel slajdu: Slajd omawia zagadnienie „Dziedziczenie i hierarchia konfiguracji (Scoping)” w kontekście: Reguły dziedziczenia i nadpisywania opcji w dhcpd.conf.

Reguły dziedziczenia i nadpisywania opcji w dhcpd.conf

Architektura pliku dhcpd.conf opiera się na hierarchicznym modelu dziedziczenia parametrów (Scoping)
Trzy poziomy hierarchii dyrektyw:
- 1. Poziom globalny (Root Scope): parametry zdefiniowane na początku pliku poza jakimkolwiek blokiem – stanowią domyślną bazę dla całej konfiguracji
- 2. Poziom podsieci (Subnet Scope): parametry zdefiniowane wewnątrz bloku subnet – nadpisują wartości globalne dla stacji z tej konkretnej podsieci
- 3. Poziom hosta (Host Scope): parametry wewnątrz bloku host – najwyższy priorytet, nadpisują zarówno parametry podsieci, jak i globalne

# Poziom globalny:
option domain-name-servers 8.8.8.8;

subnet 192.168.1.0 netmask 255.255.255.0 {
    # Nadpisanie poziomu globalnego dla podsieci biurowej:
    option domain-name-servers 192.168.1.10;
    
    host prezes-pc {
        hardware ethernet 00:11:22:33:44:55;
        fixed-address 192.168.1.99;
        # Nadpisanie dla konkretnego komputera:
        option domain-name-servers 1.1.1.1;
    }
}

Dziedziczenie i hierarchia konfiguracji (ang. Scoping): Slajd przedstawia zagadnienie Reguły dziedziczenia i nadpisywania opcji w dhcpd.conf w ramach tematu Dziedziczenie i hierarchia konfiguracji (Scoping) na przykładach konfiguracji i diagnostyki w systemie Linux. Szczegóły formatu komunikatów i opcji opisano w RFC 2131 i RFC 2132, a implementacje serwerowe dostarczają między innymi ISC DHCP i Kea.

Cel slajdu: Slajd omawia zagadnienie „Weryfikacja składni (dhcpd -t) i start usługi” w kontekście: Bezpieczne wdrażanie zmian w środowisku produkcyjnym.

Bezpieczne wdrażanie zmian w środowisku produkcyjnym

Złota zasada administratora: nigdy nie restartuj usługi serwera DHCP przed formalną weryfikacją poprawności składni pliku konfiguracyjnego!

Polecenie testowe parsera:

$ sudo dhcpd -t -cf /etc/dhcp/dhcpd.conf

Działanie opcji -t (test syntax):
- Demon wczytuje plik konfiguracyjny, parsuje wszystkie bloki i sprawdza spójność logiczną podsieci
- Nie otwiera gniazd sieciowych i nie zakłóca pracy aktualnie działającej usługi
- W przypadku błędu wyświetla dokładny numer linii oraz powód awarii (np. semicolon expected)
Wprowadzenie zmian w systemie produkcyjnym:

# 1. Test składni pliku:
$ sudo dhcpd -t -cf /etc/dhcp/dhcpd.conf && echo "Składnia poprawna!"

# 2. Przeładowanie lub restart usługi:
$ sudo systemctl restart isc-dhcp-server

# 3. Kontrola statusu procesu:
$ sudo systemctl status isc-dhcp-server

Weryfikacja składni i start usługi (ang. dhcpd -t): Slajd przedstawia zagadnienie Bezpieczne wdrażanie zmian w środowisku produkcyjnym w ramach tematu Weryfikacja składni (dhcpd -t) i start usługi na przykładach konfiguracji i diagnostyki w systemie Linux. Szczegóły formatu komunikatów i opcji opisano w RFC 2131 i RFC 2132, a implementacje serwerowe dostarczają między innymi ISC DHCP i Kea.

Cel slajdu: Slajd omawia zagadnienie „Koncepcja rezerwacji statycznych (Fixed Leases)” w kontekście: Statyczne wiązanie adresów w architekturze dynamicznej.

Statyczne wiązanie adresów w architekturze dynamicznej

Rezerwacja statyczna (Fixed Lease / Static Mapping): trwałe powiązanie konkretnego adresu IPv4 ze stałym identyfikatorem urządzenia (najczęściej adresem fizycznym MAC karty sieciowej)
Dlaczego rezerwacja DHCP jest lepsza od ręcznej konfiguracji statycznej na hoście?
- Centralizacja zarządzania: brak konieczności fizycznego podchodzenia do urządzenia w celu modyfikacji konfiguracji
- Spójność opcji sieciowych: stacja zawsze posiada ten sam adres IP, a jednocześnie automatycznie odbiera aktualizacje adresów bramy, serwerów DNS czy domen
- Eliminacja konfliktów adresowych: serwer DHCP ma pełną wiedzę o wszystkich przypisanych adresach i nie przydzieli zarezerwowanego adresu innej stacji dynamicznej
Stacja robocza przechodzi standardowy cykl DORA, lecz serwer z bazy konfiguracji wybiera dla niej zawsze ten sam z góry określony adres IP

Koncepcja rezerwacji statycznych (ang. Fixed Leases): Slajd przedstawia zagadnienie Statyczne wiązanie adresów w architekturze dynamicznej w ramach tematu Koncepcja rezerwacji statycznych (Fixed Leases) na przykładach konfiguracji i diagnostyki w systemie Linux. Szczegóły formatu komunikatów i opcji opisano w RFC 2131 i RFC 2132, a implementacje serwerowe dostarczają między innymi ISC DHCP i Kea.

Cel slajdu: Slajd omawia zagadnienie „Sposób identyfikacji: MAC Address vs Client Identifier” w kontekście: Kryteria identyfikacji stacji klienckiej (RFC 2132 Opcja 61).

Kryteria identyfikacji stacji klienckiej (RFC 2132 Opcja 61)

1. Tradycyjna identyfikacja na podstawie adresu MAC (L2):
- Identyfikator sprzętowy z nagłówka: pole chaddr (Client Hardware Address)
- Dyrektywa konfiguracyjna: hardware ethernet 00:1A:2B:3C:4D:5E;
- Wada: wymiana uszkodzonej karty sieciowej wymusza modyfikację konfiguracji serwera DHCP
2. Identyfikator logiczny klienta (DHCP Client Identifier – Opcja 61):
- Zdefiniowany w RFC 2132 ciąg bajtów przesyłany jawnie przez klienta
- Może przyjmować postać dowolnego ciągu bajtów, na przykład typu z adresem MAC albo nazwy tekstowej (identyfikator DUID w ścisłym znaczeniu dotyczy protokołu DHCPv6, RFC 8415)
- Dyrektywa konfiguracyjna w dhcpd.conf:
```
host serwer-bazy {
    dhcp-client-identifier "db-node-01";
    fixed-address 192.168.1.20;
}
```
- Zaleta: stacja zachowuje stały adres IP niezależnie od wymiany fizycznej karty sieciowej

Sposób identyfikacji: MAC Address vs Client Identifier: Slajd przedstawia zagadnienie Kryteria identyfikacji stacji klienckiej (RFC 2132 Opcja 61) w ramach tematu Sposób identyfikacji: MAC Address vs Client Identifier na przykładach poleceń oraz diagnostyki w systemach Linux, Windows i RouterOS. Szczegóły formatu komunikatów i opcji opisano w RFC 2131 i RFC 2132, a implementacje serwerowe dostarczają między innymi ISC DHCP i Kea.

Cel slajdu: Slajd omawia zagadnienie „Wdrożenie: Dyrektywa host w dhcpd.conf” w kontekście: Składnia deklaracji rezerwacji statycznych w ISC DHCP.

Składnia deklaracji rezerwacji statycznych w ISC DHCP

Deklaracja rezerwacji w pliku /etc/dhcp/dhcpd.conf odbywa się wewnątrz bloku host <nazwa> { ... }:

# Rezerwacja dla drukarki sieciowej w dziale kadr:
host prn-kadry-01 {
    hardware ethernet 00:11:22:33:44:55;
    fixed-address 192.168.1.50;
    option host-name "prn-kadry";
}

# Rezerwacja dla serwera pamięci masowej NAS z dedykowanym DNS:
host storage-nas {
    hardware ethernet 00:aa:bb:cc:dd:ee;
    fixed-address 192.168.1.20;
    option domain-name-servers 192.168.1.10;
}

Reguły składniowe bloku host:
- Nazwa bloku (np. prn-kadry-01) musi być unikalna w skali całego pliku konfiguracyjnego
- Dyrektywa fixed-address przyjmuje adres IPv4 lub w pełni kwalifikowaną nazwę FQDN resolwowalną przez DNS
- Wewnątrz bloku można definiować indywidualne opcje sieciowe dedykowane wyłącznie dla tej jednej stacji

Wdrożenie: Dyrektywa host w dhcpd.conf: Dyrektywa host w dhcpd.conf: Slajd przedstawia zagadnienie Składnia deklaracji rezerwacji statycznych w ISC DHCP w ramach tematu Wdrożenie: Dyrektywa host w dhcpd.conf na przykładach konfiguracji i diagnostyki w systemie Linux. Szczegóły formatu komunikatów i opcji opisano w RFC 2131 i RFC 2132, a implementacje serwerowe dostarczają między innymi ISC DHCP i Kea.

Cel slajdu: Slajd omawia zagadnienie „Zarządzanie pulą adresową a rezerwacje statyczne” w kontekście: Separacja adresacji dynamicznej i statycznej w podsieci.

Separacja adresacji dynamicznej i statycznej w podsieci

Fundamentalna zasada dobrej praktyki inżynierskiej:
Adresy zadeklarowane w dyrektywach fixed-address powinny bezwzględnie znajdować się POZA zakresem zdefiniowanym w dyrektywie range!
Dlaczego nie wolno umieszczać fixed-address wewnątrz range w ISC DHCP?
- Serwer ISC DHCP traktuje pulę range jako pulę w pełni dynamiczną
- Jeżeli urządzenie z rezerwacją statyczną jest wyłączone, serwer może w sytuacji deficytu przydzielić ten adres obcej stacji dynamicznej!
- Po włączeniu właściwego urządzenia dochodzi do groźnego konfliktu adresów IP w podsieci
Wzorcowy podział przestrzeni adresowej podsieci /24 (254 adresy):
- .1 – .10: bramy domyślne, routery i przełączniki L3 (statycznie na urządzeniach)
- .11 – .49: serwery lokalne i kontrolery domeny (statycznie na serwerach)
- .50 – .99: rezerwacje statyczne DHCP (fixed-address) dla drukarek, kamer i VoIP
- .100 – .240: pula dynamiczna DHCP (range) dla stacji roboczych i laptopów
- .241 – .254: rezerwa administracyjna na przyszłe rozbudowy

Zarządzanie pulą adresową a rezerwacje statyczne: Slajd przedstawia zagadnienie Separacja adresacji dynamicznej i statycznej w podsieci w ramach tematu Zarządzanie pulą adresową a rezerwacje statyczne na przykładach konfiguracji i diagnostyki w systemie Linux. Szczegóły formatu komunikatów i opcji opisano w RFC 2131 i RFC 2132, a implementacje serwerowe dostarczają między innymi ISC DHCP i Kea.

Cel slajdu: Slajd omawia zagadnienie „Infrastruktura peryferyjna – drukarki i specyfika sieci” w kontekście: Automatyzacja konfiguracji urządzeń peryferyjnych i telefonii VoIP.

Automatyzacja konfiguracji urządzeń peryferyjnych i telefonii VoIP

Urządzenia peryferyjne (sieciowe urządzenia wielofunkcyjne, kamery CCTV, terminale POS) wymagają stabilnego adresu IP dla poprawnego działania usług w organizacji
Zalety obsługi przez rezerwacje DHCP w porównaniu z konfiguracją ręczną:
- Automatyczna aktualizacja serwerów czasu NTP i parametrów syslog
- Możliwość masowej podmiany adresów serwerów wydruku i bramek pocztowych SMTP
Specjalistyczne opcje DHCP w infrastrukturze korporacyjnej:
- Opcja 66 (TFTP Server Name) & Opcja 67 (Bootfile Name): konfiguracja bezdyskowego uruchamiania stacji przez sieć (standard PXE)
- Opcja 150 / 66: przekazywanie listy adresów serwerów zarządzających telefonii VoIP (np. Cisco Unified Communications Manager) w celu automatycznego pobrania profili telefonów IP
- Opcja 43 (Vendor-Specific Information): automatyczne odnajdywanie kontrolera sieci bezprzewodowej przez punkty dostępowe Wi-Fi (np. Cisco WLC, Aruba)

Infrastruktura peryferyjna – drukarki i specyfika sieci: Slajd przedstawia zagadnienie Automatyzacja konfiguracji urządzeń peryferyjnych i telefonii VoIP w ramach tematu Infrastruktura peryferyjna – drukarki i specyfika sieci na przykładach konfiguracji i diagnostyki w systemie Linux. Szczegóły formatu komunikatów i opcji opisano w RFC 2131 i RFC 2132, a implementacje serwerowe dostarczają między innymi ISC DHCP i Kea.

Cel slajdu: Slajd omawia zagadnienie „Serwery aplikacji i węzły zarządzające (Management)” w kontekście: Adresowanie interfejsów Out-of-Band (IPMI / iLO / iDRAC).

Adresowanie interfejsów Out-of-Band (IPMI / iLO / iDRAC)

Węzły obliczeniowe i serwery w centrach danych posiadają niezależne, wydzielone interfejsy zarządzania pozapasmowego (Out-of-Band Management – OOB):
- HPE iLO (Integrated Lights-Out)
- Dell iDRAC (Integrated Dell Remote Access Controller)
- Standard przemysłowy IPMI (Intelligent Platform Management Interface)
Praktyka zarządzania adresacją OOB:
- Interfejsy zarządzające podłącza się do fizycznie wydzielonego VLAN-u zarządzającego (Management VLAN), całkowicie odseparowanego od ruchu produkcyjnego
- Stosuje się rezerwacje DHCP powiązane z adresami MAC portów zarządzających serwerów
Korzyści inżynierskie:
- Szybka inwentaryzacja sprzętowa (system DHCP rejestruje obecność modułów w szafie rack)
- Możliwość natychmiastowego uzyskania konsoli wideo KVM i zdalnego włączenia zasilania nowego serwera bez konieczności podłączania monitora i klawiatury

Serwery aplikacji i węzły zarządzające (ang. Management): Slajd przedstawia zagadnienie Adresowanie interfejsów Out-of-Band (IPMI / iLO / iDRAC) w ramach tematu Serwery aplikacji i węzły zarządzające (Management) na przykładach konfiguracji i diagnostyki w systemie Linux. Szczegóły formatu komunikatów i opcji opisano w RFC 2131 i RFC 2132, a implementacje serwerowe dostarczają między innymi ISC DHCP i Kea.

Cel slajdu: Slajd omawia zagadnienie „Konflikty adresacyjne – pułapki twardych dzierżaw” w kontekście: Problemy kolizji adresów w środowiskach wirtualnych i chmurze.

Problemy kolizji adresów w środowiskach wirtualnych i chmurze

Zjawisko duplikacji adresu fizycznego (MAC Spoofing / Collision):
- Najczęstsza przyczyna: omyłkowe klonowanie maszyn wirtualnych w środowiskach VMware ESXi, Proxmox lub Hyper-V bez zaznaczenia opcji wygenerowania nowego adresu MAC
- Dwie działające maszyny posiadają identyczny adres MAC w tym samym segmencie L2!
Konsekwencje dla serwera DHCP i przełącznika L2:
- Przełącznik L2 doświadcza zjawiska MAC Flapping: adres MAC przeskakuje między dwoma portami fizycznymi setki razy na sekundę
- Serwer DHCP otrzymuje zapytania z tego samego adresu MAC, przydzielając ten sam adres IP obu maszynom na zmianę
- Połączenia sieciowe obu maszyn są nieustannie zrywane (naprzemienna utrata pakietów)
Metody zapobiegania:
- Stosowanie szablonów wirtualizacji (Cloud-Init) z automatycznym losowaniem adresu MAC
- Identyfikacja klientów za pomocą unikalnego identyfikatora klienta (opcja 61) zamiast surowego MAC
- Włączenie na przełącznikach funkcji MAC Flapping Detection z automatycznym blokowaniem portu

Konflikty adresacyjne – pułapki twardych dzierżaw: Slajd przedstawia zagadnienie Problemy kolizji adresów w środowiskach wirtualnych i chmurze w ramach tematu Konflikty adresacyjne – pułapki twardych dzierżaw na przykładach konfiguracji i diagnostyki w systemie Linux. Szczegóły formatu komunikatów i opcji opisano w RFC 2131 i RFC 2132, a implementacje serwerowe dostarczają między innymi ISC DHCP i Kea.

Cel slajdu: Slajd omawia zagadnienie „Zarządzanie IPAM (IP Address Management)” w kontekście: Integracja usług DHCP z centralnymi systemami zarządzania adresacją.

Integracja usług DHCP z centralnymi systemami zarządzania adresacją

W rozległych sieciach przedsiębiorstw (dziesiątki podsieci, tysiące urządzeń) ręczna edycja plików tekstowych dhcpd.conf staje się nieefektywna i podatna na błędy
Systemy klasy IPAM (IP Address Management):
- Centralna, zintegrowana baza danych przechowująca pełną dokumentację przestrzeni adresowej IPv4 i IPv6, sieci VLAN, urządzeń i lokalizacji
- Popularne rozwiązania open-source: NetBox (standard de facto w automatyzacji), phpIPAM
- Rozwiązania komercyjne klasy DDI (DNS-DHCP-IPAM): Infoblox, BlueCat, Men&Mice
Nowoczesna automatyzacja (Infrastructure as Code):
- System IPAM stanowi nadrzędne źródło prawdy (Single Source of Truth)
- Konfiguracje serwerów DHCP są generowane w pełni automatycznie za pomocą skryptów w języku Python lub playbooków Ansible odpytujących REST API systemu NetBox
- Eliminacja ręcznych pomyłek i natychmiastowa spójność dokumentacji z rzeczywistym stanem sieci

Zarządzanie IPAM (ang. IP Address Management): Slajd przedstawia zagadnienie Integracja usług DHCP z centralnymi systemami zarządzania adresacją w ramach tematu Zarządzanie IPAM (IP Address Management) na przykładach konfiguracji i diagnostyki w systemie Linux. Szczegóły formatu komunikatów i opcji opisano w RFC 2131 i RFC 2132, a implementacje serwerowe dostarczają między innymi ISC DHCP i Kea.

Cel slajdu: Slajd omawia zagadnienie „DHCP Relay – mostowanie rozległych architektur” w kontekście: Przekazywanie zapytań DHCP między różnymi segmentami sieci.

Przekazywanie zapytań DHCP między różnymi segmentami sieci

Problem architektoniczny w sieciach kampusowych:
- Struktura sieci jest podzielona na dziesiątki wirtualnych sieci LAN (VLAN-ów) w celu izolacji ruchu i bezpieczeństwa
- Zapytanie DHCPDISCOVER jest pakietem rozgłoszeniowym (Broadcast) – nie przekracza granicy routera L3
- Czy konieczne jest instalowanie fizycznego serwera DHCP w każdym osobnym VLAN-ie? Nie!
Rozwiązanie inżynierskie: Agent przekazywania (DHCP Relay Agent):
- Wyspecjalizowana usługa uruchomiona na routerze domyślnym lub przełączniku warstwy 3 (L3 Switch)
- Odbiera lokalny pakiet broadcast od klienta, przekształca go w standardowy pakiet Unicast L3 i przesyła przez sieć do centralnego serwera DHCP
- Odbiera odpowiedź Unicast od serwera centralnego i odsyła ją do klienta w lokalnym VLAN-ie
Korzyści: centralizacja zarządzania, wysoka dostępność w centrum danych, redukcja kosztów infrastruktury

DHCP Relay – mostowanie rozległych architektur: Slajd przedstawia zagadnienie Przekazywanie zapytań DHCP między różnymi segmentami sieci w ramach tematu DHCP Relay – mostowanie rozległych architektur na przykładach konfiguracji i diagnostyki w systemie Linux. Szczegóły formatu komunikatów i opcji opisano w RFC 2131 i RFC 2132, a implementacje serwerowe dostarczają między innymi ISC DHCP i Kea.

Cel slajdu: Slajd omawia zagadnienie „Bariera routera L3 – dlaczego Broadcast upada” w kontekście: Granica domeny rozgłoszeniowej a standardy routingu IP (RFC 1812).

Granica domeny rozgłoszeniowej a standardy routingu IP (RFC 1812)

Fundamentalna zasada routingu IP (RFC 1812 – Requirements for IP Version 4 Routers):
Router warstwy 3 pod żadnym pozorem nie przekazuje pakietów skierowanych na adres rozgłoszeniowy Limited Broadcast (255.255.255.255) poza lokalny interfejs!
Dlaczego ta reguła jest krytyczna dla całego Internetu?
- Gdyby routery przekazywały pakiety rozgłoszeniowe, pojedyncza burza rozgłoszeniowa w małej sieci lokalnej zalałaby całą sieć operatora i doprowadziła do globalnego paraliżu łączy tranzytowych
- Każdy interfejs routera L3 stanowi szczelną granicę domeny rozgłoszeniowej (Broadcast Domain)
Konsekwencja dla protokołu DHCP:
- Klient wysyłający pakiet DHCPDISCOVER na adres 255.255.255.255 „odbija się” od interfejsu bramy domyślnej
- Bez aktywnej usługi DHCP Relay pakiet zostaje bezpowrotnie odrzucony przez procesor routera

Bariera routera L3 – dlaczego Broadcast upada: Slajd przedstawia zagadnienie Granica domeny rozgłoszeniowej a standardy routingu IP (RFC 1812) w ramach tematu Bariera routera L3 – dlaczego Broadcast upada na przykładach konfiguracji i diagnostyki w systemie Linux. Szczegóły formatu komunikatów i opcji opisano w RFC 2131 i RFC 2132, a implementacje serwerowe dostarczają między innymi ISC DHCP i Kea.

Cel slajdu: Slajd omawia zagadnienie „Koncepcja translacji L2 Broadcast na L3 Unicast” w kontekście: Szczegółowy mechanizm działania agenta DHCP Relay.

Szczegółowy mechanizm działania agenta DHCP Relay

Przebieg procedury przekazywania zapytań krok po kroku:
- 1. Klient w sieci 192.168.10.0/24 rozsyła pakiet DHCPDISCOVER (Broadcast L2/L3)
- 2. Interfejs routera (np. subinterfejs VLAN 10 z adresem 192.168.10.1) przechwytuje pakiet na porcie UDP 67
- 3. Proces Relay Agent analizuje nagłówek DHCP i wstawia adres swojego interfejsu (192.168.10.1) do pola giaddr (Gateway IP Address)
- 4. Agent zwiększa licznik przeskoków (pole hops o 1)
- 5. Agent tworzy nowy, standardowy datagram Unicast IPv4:
  - IP źródłowy: 192.168.10.1 (lub adres interfejsu wyjściowego routera)
  - IP docelowy: 10.0.0.100 (adres centralnego serwera DHCP)
- 6. Centralny serwer DHCP odbiera pakiet Unicast i na podstawie pola giaddr precyzyjnie identyfikuje podsieć klienta!

Koncepcja translacji L2 Broadcast na L3 Unicast: Slajd przedstawia zagadnienie Szczegółowy mechanizm działania agenta DHCP Relay w ramach tematu Koncepcja translacji L2 Broadcast na L3 Unicast na przykładach konfiguracji i diagnostyki w systemie Linux. Szczegóły formatu komunikatów i opcji opisano w RFC 2131 i RFC 2132, a implementacje serwerowe dostarczają między innymi ISC DHCP i Kea.

Cel slajdu: Slajd omawia zagadnienie „Konfiguracja Relay na urządzeniach sieciowych L3” w kontekście: Wdrażanie funkcji przekazywania w Cisco IOS i MikroTik RouterOS.

Wdrażanie funkcji przekazywania w Cisco IOS i MikroTik RouterOS

Przełącznik warstwy 3 / Router Cisco IOS (komenda ip helper-address):
- Konfiguracja realizowana jest bezpośrednio na interfejsie wirtualnym podsieci (SVI) lub porcie trasowanym:
```
Switch(config)# interface Vlan 10
Switch(config-if)# ip address 192.168.10.1 255.255.255.0
Switch(config-if)# ip helper-address 10.0.0.100
Switch(config-if)# exit
```
Uwaga techniczna: Polecenie ip helper-address w Cisco domyślnie przekazuje nie tylko DHCP (porty 67/68), ale również ruch UDP na portach DNS (53), TFTP (69), Time (37), TACACS (49) oraz NetBIOS (137/138).
Router MikroTik RouterOS (menu /ip dhcp-relay):

/ip dhcp-relay add name=relay-vlan10 interface=vlan10     dhcp-server=10.0.0.100 local-address=192.168.10.1 disabled=no

Konfiguracja Relay na urządzeniach sieciowych L3: Slajd przedstawia zagadnienie Wdrażanie funkcji przekazywania w Cisco IOS i MikroTik RouterOS w ramach tematu Konfiguracja Relay na urządzeniach sieciowych L3 na przykładach poleceń oraz diagnostyki w systemach Linux, Windows i RouterOS. Szczegóły formatu komunikatów i opcji opisano w RFC 2131 i RFC 2132, a implementacje serwerowe dostarczają między innymi ISC DHCP i Kea.

Cel slajdu: Slajd omawia zagadnienie „Agent przekazywania w systemie Linux (narzędzie dhcrelay)” w kontekście: Konfiguracja usługi DHCP Relay w środowisku uniksowym.

Konfiguracja usługi DHCP Relay w środowisku uniksowym

Pakiet oprogramowania w dystrybucjach Debian / Ubuntu: isc-dhcp-relay
Uruchomienie procesu agenta przekazywania w wierszu poleceń:
```
$ sudo dhcrelay -i eth1 -i eth2 10.0.0.100
```
- Opcja -i eth1: interfejs nasłuchujący od strony podsieci klientów (nasłuch na porcie UDP 67)
- Opcja -i eth2: interfejs wyjściowy prowadzący w stronę centralnego serwera DHCP
- Adres 10.0.0.100: docelowy adres IPv4 centralnego serwera DHCP
Warunek bezwzględny po stronie jądra Linux:
- Serwer pełniący rolę przekaźnika musi posiadać włączone przekazywanie pakietów (routing IP) w jądrze:
```
$ sudo sysctl -w net.ipv4.ip_forward=1
```
Konfiguracja stała w pliku środowiskowym: /etc/default/isc-dhcp-relay (zmienne SERVERS oraz INTERFACES)

Agent przekazywania w systemie Linux (narzędzie dhcrelay): Slajd przedstawia zagadnienie Konfiguracja usługi DHCP Relay w środowisku uniksowym w ramach tematu Agent przekazywania w systemie Linux (narzędzie dhcrelay) na przykładach konfiguracji i diagnostyki w systemie Linux. Szczegóły formatu komunikatów i opcji opisano w RFC 2131 i RFC 2132, a implementacje serwerowe dostarczają między innymi ISC DHCP i Kea.

Cel slajdu: Slajd omawia zagadnienie „Pole giaddr i Opcja 82 (Relay Information Option)” w kontekście: Lokalizacja fizyczna klienta a Opcja 82 (standard RFC 3046).

Lokalizacja fizyczna klienta a Opcja 82 (standard RFC 3046)

Rola pola giaddr (Gateway IP Address, 4 bajty w nagłówku):
- Pole obowiązkowe przy stosowaniu przekaźnika – wskazuje adres IP interfejsu bramy lokalnej
- Kryterium wyboru podsieci: serwer DHCP dopasowuje pole giaddr do zadeklarowanego bloku subnet
Opcja 82 (DHCP Relay Agent Information Option wg RFC 3046):
- Umożliwia przełącznikowi lub przekaźnikowi wstrzyknięcie dodatkowych metadanych o fizycznej lokalizacji stacji
- Podopcja 1: Circuit ID – identyfikator obwodu (dokładny numer portu przełącznika i numer VLAN-u, z którego nadeszła ramka)
- Podopcja 2: Remote ID – unikalny identyfikator przełącznika (najczęściej adres MAC przełącznika dostępowego)
Zastosowanie w telekomunikacji (ISP / FTTH / DOCSIS):
- Przydział konkretnego adresu IP bezpośrednio na podstawie numeru gniazdka ściennego lub portu OLT/DSLAM, całkowicie niezależnie od adresu MAC urządzenia klienta!

Pole giaddr i Opcja 82 (ang. Relay Information Option): Slajd przedstawia zagadnienie Lokalizacja fizyczna klienta a Opcja 82 (standard RFC 3046) w ramach tematu Pole giaddr i Opcja 82 (Relay Information Option) na przykładach konfiguracji i diagnostyki w systemie Linux. Szczegóły formatu komunikatów i opcji opisano w RFC 2131 i RFC 2132, a implementacje serwerowe dostarczają między innymi ISC DHCP i Kea.

Cel slajdu: Slajd omawia zagadnienie „Laboratorium 1: Podgląd bazy dzierżaw dhcpd.leases” w kontekście: Inspekcja pliku stanu bazy dzierżaw w serwerze ISC DHCP.

Inspekcja pliku stanu bazy dzierżaw w serwerze ISC DHCP

Domyślna lokalizacja pliku stanu dzierżaw w Linux: /var/lib/dhcp/dhcpd.leases
Plik prowadzony jest w trybie dopisywania transakcyjnego (append-only) – nowy stan nadpisuje wpis poprzedni
Anatomia pojedynczego rekordu dzierżawy:

lease 192.168.1.105 {
  starts 4 2026/10/01 10:15:30;
  ends 5 2026/10/02 10:15:30;
  tstp 5 2026/10/02 10:15:30;
  cltt 4 2026/10/01 10:15:30;
  binding state active;
  next binding state free;
  hardware ethernet 08:00:27:8f:22:60;
  client-hostname "stacja-graficzna-01";
}

Interpretacja kluczowych atrybutów:
- starts / ends: znaczniki czasu UTC początku i wygaśnięcia dzierżawy
- binding state active: dzierżawa jest aktualnie aktywna i w pełni ważna
- client-hostname: nazwa hosta zgłoszona przez stację roboczą (Opcja 12)
Szybkie zestawienie aktywnych dzierżaw w konsoli: program dhcp-lease-list (skrypt dostarczany z pakietem isc-dhcp-server)

Laboratorium 1: Podgląd bazy dzierżaw dhcpd.leases: Podgląd bazy dzierżaw dhcpd.leases: Slajd przedstawia zagadnienie Inspekcja pliku stanu bazy dzierżaw w serwerze ISC DHCP w ramach tematu Laboratorium 1: Podgląd bazy dzierżaw dhcpd.leases na przykładach konfiguracji i diagnostyki w systemie Linux. Szczegóły formatu komunikatów i opcji opisano w RFC 2131 i RFC 2132, a implementacje serwerowe dostarczają między innymi ISC DHCP i Kea.

Cel slajdu: Slajd omawia zagadnienie „Laboratorium 2: Diagnostyka i monitoring w dziennikach systemowych” w kontekście: Śledzenie zdarzeń serwera DHCP za pomocą journalctl i syslog.

Śledzenie zdarzeń serwera DHCP za pomocą journalctl i syslog

Współczesne systemy Linux z systemd rejestrują zdarzenia demona w usłudze systemd-journald
Podgląd strumienia zdarzeń w czasie rzeczywistym:
```
$ sudo journalctl -u isc-dhcp-server -f
```
Wzorcowy przebieg pełnego cyklu DORA w logach serwera:

dhcpd[1245]: DHCPDISCOVER from 08:00:27:8f:22:60 via eth0
dhcpd[1245]: DHCPOFFER on 192.168.1.105 to 08:00:27:8f:22:60 (stacja-01) via eth0
dhcpd[1245]: DHCPREQUEST for 192.168.1.105 (192.168.1.1) from 08:00:27:8f:22:60 (stacja-01) via eth0
dhcpd[1245]: DHCPACK on 192.168.1.105 to 08:00:27:8f:22:60 (stacja-01) via eth0

Typowe komunikaty ostrzegawcze i błędy:
- DHCPNAK on ... to ... via eth0: odrzucenie żądania stacji (np. błędna podsieć)
- peer holds all free leases: całkowite wyczerpanie puli adresowej w zdefiniowanym zakresie
- ICMP Echo Reply received from 192.168.1.105... abandoned!: wykryto kolizję IP w podsieci!

Laboratorium 2: Diagnostyka i monitoring w dziennikach systemowych: Diagnostyka i monitoring w dziennikach systemowych: Slajd przedstawia zagadnienie Śledzenie zdarzeń serwera DHCP za pomocą journalctl i syslog w ramach tematu Laboratorium 2: Diagnostyka i monitoring w dziennikach systemowych na przykładach konfiguracji i diagnostyki w systemie Linux. Szczegóły formatu komunikatów i opcji opisano w RFC 2131 i RFC 2132, a implementacje serwerowe dostarczają między innymi ISC DHCP i Kea.

Cel slajdu: Slajd omawia zagadnienie „Laboratorium 3: Konsolowe wymuszanie dzierżawy u klienta” w kontekście: Sterowanie procesem DHCP po stronie stacji roboczej.

Sterowanie procesem DHCP po stronie stacji roboczej

System Linux (narzędzie dhclient z pakietu isc-dhcp-client):
- Zwolnienie posiadanej dzierżawy (wysłanie DHCPRELEASE):
```
$ sudo dhclient -r eth0
```
- Wymuszenie nowego cyklu DORA z pełnym logowaniem w terminalu (tryb gadatliwy):
```
$ sudo dhclient -v eth0
```
System Windows (wiersz poleceń CMD / PowerShell):
- Zwolnienie konfiguracji IP: ipconfig /release
- Wysłanie żądania i odnowienie dzierżawy: ipconfig /renew
- Szczegółowy podgląd czasów dzierżawy i serwera (PowerShell): Get-NetIPConfiguration
MikroTik RouterOS (zarządzanie klientem DHCP):

/ip dhcp-client print detail              # Wyświetlenie stanu i parametrów
/ip dhcp-client release [find]            # Wysłanie DHCPRELEASE do serwera
/ip dhcp-client renew [find]              # Wymuszenie odnowienia dzierżawy

Laboratorium 3: Konsolowe wymuszanie dzierżawy u klienta: Slajd przedstawia zagadnienie Sterowanie procesem DHCP po stronie stacji roboczej w ramach tematu Laboratorium 3: Konsolowe wymuszanie dzierżawy u klienta na przykładach poleceń oraz diagnostyki w systemach Linux, Windows i RouterOS. Szczegóły formatu komunikatów i opcji opisano w RFC 2131 i RFC 2132, a implementacje serwerowe dostarczają między innymi ISC DHCP i Kea.

Cel slajdu: Slajd omawia zagadnienie „Laboratorium 4: Analiza pakietów DHCP za pomocą tcpdump” w kontekście: Zaawansowane filtrowanie i dekompozycja ramek protokołu BOOTP/DHCP.

Zaawansowane filtrowanie i dekompozycja ramek protokołu BOOTP/DHCP

Precyzyjny filtr tcpdump dla ruchu DHCP na interfejsie serwera lub stacji:
```
$ sudo tcpdump -i eth0 -nn -vvv -s 0 port 67 or port 68
```
Znaczenie przełączników polecenia:
- -i eth0: wskazanie badanego interfejsu sieciowego
- -nn: wyłączenie rozwiązywania nazw domenowych oraz portów (szybkość analizy)
- -vvv: maksymalny poziom szczegółowości (dekompozycja pól nagłówka i opcji DHCP)
- -s 0: przechwytywanie pełnego pakietu bez obcinania ładunku (snaplen = cały pakiet)
- port 67 or port 68: filtracja wyłącznie ruchu protokołu BOOTP/DHCP
Kluczowe pola do weryfikacji w zrzucie pakietów:
- Identyfikator transakcji: xid 0x3a4f891b (musi być zgodny w zapytaniu i odpowiedzi)
- Adres fizyczny w zapytaniu: chaddr 08:00:27:8f:22:60
- Pole opcji: DHCP-Message (53), length 1: Discover / Offer / Request / ACK
- Opcje sieciowe: Opcja 1 (Maska), Opcja 3 (Router), Opcja 6 (DNS), Opcja 51 (Lease Time)

Laboratorium 4: Analiza pakietów DHCP za pomocą tcpdump: Analiza pakietów DHCP za pomocą tcpdump: Slajd przedstawia zagadnienie Zaawansowane filtrowanie i dekompozycja ramek protokołu BOOTP/DHCP w ramach tematu Laboratorium 4: Analiza pakietów DHCP za pomocą tcpdump na przykładach konfiguracji i diagnostyki w systemie Linux. Szczegóły formatu komunikatów i opcji opisano w RFC 2131 i RFC 2132, a implementacje serwerowe dostarczają między innymi ISC DHCP i Kea.

Cel slajdu: Slajd omawia zagadnienie „Bezpieczeństwo DHCP: Rogue DHCP i ataki Starvation” w kontekście: Zagrożenia w warstwie 2 i sprzętowa ochrona DHCP Snooping.

Zagrożenia w warstwie 2 i sprzętowa ochrona DHCP Snooping

1. Zagrożenie: Nieautoryzowany serwer DHCP (Rogue DHCP Server):
- Omyłkowe wpięcie routera domowego do sieci LAN lub celowy atak Man-in-the-Middle (MitM)
- Nieautoryzowany serwer odpowiada na zapytania DHCPDISCOVER szybciej niż serwer produkcyjny, przydzielając stacjom fałszywą bramę domyślną i fałszywy DNS (przechwytywanie całego ruchu użytkowników!)
- Kwalifikacja prawna ataku: art. 267 k.k. (nieuprawnione uzyskanie informacji) oraz art. 268a k.k. (zakłócanie pracy systemu)
2. Zagrożenie: Wyczerpanie puli adresowej (DHCP Starvation Attack):
- Złośliwe narzędzie (np. yersinia) zalewa serwer tysiącami zapytań z losowymi adresami MAC, powodując natychmiastowe zablokowanie wszystkich wolnych adresów w puli (atak DoS)
3. Skuteczna ochrona: DHCP Snooping na przełącznikach warstwy 2:
- Przełącznik L2 analizuje pakiety DHCP w locie i dzieli porty na:
  - Porty zaufane (Trusted): porty uplinkowe prowadzące do autoryzowanego serwera DHCP
  - Porty niezaufane (Untrusted): porty dostępowe dla stacji roboczych – przełącznik bezwzględnie blokuje pakiety DHCPOFFER i DHCPACK nadchodzące z tych portów!
- Ograniczanie liczby zapytań (Rate Limiting) zapobiega atakom DHCP Starvation

Bezpieczeństwo DHCP: Rogue DHCP i ataki Starvation: Rogue DHCP i ataki Starvation: Slajd przedstawia zagadnienie Zagrożenia w warstwie 2 i sprzętowa ochrona DHCP Snooping w ramach tematu Bezpieczeństwo DHCP: Rogue DHCP i ataki Starvation na przykładach konfiguracji i diagnostyki w systemie Linux. Szczegóły formatu komunikatów i opcji opisano w RFC 2131 i RFC 2132, a implementacje serwerowe dostarczają między innymi ISC DHCP i Kea.

Cel slajdu: Slajd omawia zagadnienie „Ściąga administratora (Cheat Sheet)” w kontekście: Zestawienie kluczowych poleceń i plików w Linux, Windows i RouterOS.

Zestawienie kluczowych poleceń i plików w Linux, Windows i RouterOS

Zadanie administracyjne	System Linux (ISC DHCP / iproute2)	System Windows (PowerShell / CMD)	MikroTik RouterOS
Główny plik konfiguracji	`/etc/dhcp/dhcpd.conf`	Konsola DHCP (`dhcpmgmt.msc`)	Menu `/ip dhcp-server`
Plik deklaracji interfejsu	`/etc/default/isc-dhcp-server`	Właściwości karty sieciowej	Parametr `interface=...`
Baza aktywnych dzierżaw	`/var/lib/dhcp/dhcpd.leases`	Baza JET (`C:\Windows\system32\dhcp`)	`/ip dhcp-server lease print`
Weryfikacja składni pliku	`sudo dhcpd -t -cf /etc/dhcp/dhcpd.conf`	Kontrola w kreatorze konsoli DHCP	Walidacja przy zatwierdzaniu polecenia
Podgląd logów w locie	`sudo journalctl -u isc-dhcp-server -f`	Podgląd zdarzeń (Event Viewer)	`/log print follow where topics~"dhcp"`
Zwolnienie adresu (klient)	`sudo dhclient -r eth0`	`ipconfig /release`	`/ip dhcp-client release [find]`
Wymuszenie dzierżawy (klient)	`sudo dhclient -v eth0`	`ipconfig /renew`	`/ip dhcp-client renew [find]`
Sniffing pakietów DHCP	`sudo tcpdump -i eth0 -nn port 67 or port 68`	`pktmon filter add dhcp -t UDP -p 67`, `pktmon start`	`/tool sniffer quick filter-port=67,68`
Konfiguracja DHCP Relay	`sudo dhcrelay -i eth1 -i eth2 <IP>`	Rola DHCP Relay Agent (RRAS)	`/ip dhcp-relay add ...`
Weryfikacja dzierżaw klienta	`cat /var/lib/dhclient/dhclient.leases`	`Get-NetIPConfiguration`	`/ip dhcp-client print detail`

Ściąga administratora (ang. Cheat Sheet): Slajd przedstawia zagadnienie Zestawienie kluczowych poleceń i plików w Linux, Windows i RouterOS w ramach tematu Ściąga administratora (Cheat Sheet) na przykładach poleceń oraz diagnostyki w systemach Linux, Windows i RouterOS. Szczegóły formatu komunikatów i opcji opisano w RFC 2131 i RFC 2132, a implementacje serwerowe dostarczają między innymi ISC DHCP i Kea.