Serwer DHCP nie odpowiada klientowi Windows

Serwer DHCP nieodpowiadający klientowi Windows wskazuje na przeciążony lub wyłączony serwer DHCP w sieci lokalnej.

Jak klient Windows rozpoznaje brak odpowiedzi DHCP

Dynamic Host Configuration Protocol, czyli DHCP, służy do automatycznego przekazywania klientowi parametrów potrzebnych do pracy w sieci. Komputer z systemem Windows może otrzymać w ten sposób adres IPv4, maskę podsieci, bramę domyślną oraz adresy serwerów DNS. Jeżeli klient nie ma jeszcze adresu, rozpoczyna procedurę od komunikatu DHCPDISCOVER wysyłanego jako rozgłoszenie w lokalnym segmencie sieci. Serwer DHCP powinien odpowiedzieć komunikatem DHCPOFFER zawierającym proponowaną konfigurację.

Po otrzymaniu oferty Windows wysyła DHCPREQUEST, wskazując wybraną konfigurację, a serwer potwierdza ją komunikatem DHCPACK. Brak odpowiedzi może wystąpić na każdym z tych etapów. Sam komunikat o nieuzyskaniu adresu nie dowodzi jeszcze, że serwer jest przeciążony. Przyczyną może być również wyłączona usługa DHCP, zerwane połączenie z punktem dostępowym, nieprawidłowa konfiguracja przełącznika, filtracja ruchu albo problem z przekazywaniem żądań między podsieciami.

Adres APIPA i objawy widoczne w systemie Windows

Jeżeli klient Windows nie otrzyma dzierżawy DHCP, system może automatycznie zastosować adresowanie APIPA, czyli Automatic Private IP Addressing. Dla IPv4 jest to adres z zakresu 169.254.0.0/16, zwykle widoczny jako adres zaczynający się od 169.254. Taka konfiguracja pozwala na ograniczoną komunikację z innymi urządzeniami używającymi APIPA w tym samym segmencie, ale nie zapewnia prawidłowego dostępu do sieci za pośrednictwem bramy domyślnej.

Objawami problemu są między innymi komunikaty „Brak dostępu do Internetu”, „Nie można odnaleźć adresu IP” albo brak dostępu do zasobów sieciowych. Warto odróżnić błąd DHCP od awarii DNS. Jeżeli komputer ma poprawny adres IPv4, maskę i bramę, lecz nie otwiera nazw domenowych, problem może dotyczyć rozwiązywania nazw. Jeżeli natomiast konfiguracja zawiera adres APIPA, puste pola bramy lub nieoczekiwane wartości, pierwszeństwo ma sprawdzenie uzyskiwania konfiguracji od DHCP.

Sprawdzenie dzierżawy, interfejsu i drogi do serwera

Podstawowe informacje o konfiguracji można odczytać w wierszu polecenia za pomocą ipconfig /all. Wynik pokazuje między innymi aktywny interfejs, adres fizyczny karty, włączone DHCP, adres serwera DHCP, uzyskany adres IPv4, maskę, bramę domyślną oraz czas dzierżawy. Szczególnie ważne jest sprawdzenie, czy analizowany jest właściwy interfejs. Nieaktywny adapter Wi-Fi, odłączony Ethernet, wirtualna karta VPN lub most sieciowy mogą powodować błędną interpretację wyników.

Polecenia ipconfig /release i ipconfig /renew pozwalają odpowiednio zwolnić dotychczasową konfigurację i ponowić żądanie dzierżawy. Jeżeli odnowienie kończy się błędem, należy sprawdzić połączenie fizyczne lub radiowe, stan routera albo punktu dostępowego oraz to, czy inne urządzenia w tej samej sieci również nie otrzymują adresów. Gdy problem występuje tylko w jednej podsieci, istotne są ustawienia VLAN, portu przełącznika i funkcji DHCP relay. DHCP relay przekazuje żądania rozgłoszeniowe do serwera znajdującego się poza lokalną podsiecią; jego brak lub niepoprawny adres może uniemożliwić odpowiedź mimo prawidłowej pracy samego serwera.

W środowisku Windows zdarzenia związane z kartą sieciową i uzyskiwaniem konfiguracji mogą być zapisane w Podglądzie zdarzeń. Przydatne jest również porównanie konfiguracji z działającym komputerem oraz sprawdzenie, czy serwer ma wolne adresy w odpowiedniej puli. Jeżeli pula została wyczerpana, serwer może działać poprawnie, ale nie będzie miał czego przydzielić nowemu klientowi. Należy też zweryfikować konflikt adresów, wygasłe lub zbyt krótkie dzierżawy oraz reguły bezpieczeństwa blokujące ruch DHCP.

Naprawa po ustaleniu źródła problemu

Usuwanie usterki powinno rozpocząć się od ustalenia, czy problem dotyczy jednego komputera, jednego segmentu sieci, czy wszystkich klientów. W przypadku pojedynczego klienta sprawdza się ustawienie „Uzyskaj adres IP automatycznie”, sterownik karty sieciowej, stan interfejsu oraz połączenie z siecią. W przypadku wielu urządzeń należy skontrolować dostępność usługi DHCP, zakres przydzielanych adresów, połączenie serwera z siecią oraz urządzenia pośredniczące. Restart urządzenia może być działaniem tymczasowym, ale nie zastępuje sprawdzenia przyczyny przeciążenia, wyczerpania puli lub błędnej konfiguracji.

Po przywróceniu odpowiedzi DHCP klient powinien otrzymać adres z właściwej podsieci, poprawną maskę, bramę domyślną i serwery DNS. Wynik można ponownie potwierdzić poleceniem ipconfig /all, a łączność z bramą sprawdzić za pomocą ping. Test ten nie potwierdza jednak działania DNS ani dostępu do Internetu, dlatego dalsza weryfikacja powinna obejmować także rozwiązywanie nazw i komunikację z wymaganymi zasobami. Przy utrzymującym się problemie potrzebna jest analiza konfiguracji sieci, dzienników zdarzeń i ruchu DHCP na odpowiednim odcinku infrastruktury.