Brak synchronizacji adresów przez DHCPv6 relay

Brak synchronizacji adresów przez DHCPv6 relay wskazuje na niepoprawną konfigurację przekazywania żądań DHCPv6 między podsieciami przez router.

Brak synchronizacji adresów przez DHCPv6 relay — czym jest problem

Brak synchronizacji adresów przez DHCPv6 relay oznacza sytuację, w której urządzenia znajdujące się poza bezpośrednim segmentem serwera DHCPv6 nie otrzymują poprawnych parametrów sieciowych albo otrzymują je z opóźnieniem i w niepełnym zakresie. Mechanizm relay służy do przekazywania komunikatów DHCPv6 pomiędzy różnymi podsieciami. Router lub inne urządzenie warstwy trzeciej odbiera zapytanie klienta, dodaje informacje potrzebne do rozpoznania lokalnego segmentu, a następnie wysyła komunikat do właściwego serwera DHCPv6. Odpowiedź powinna wrócić tą samą logiczną drogą do klienta.

Nie jest to zwykle awaria samego adresu IPv6. Przyczyną może być przerwanie któregoś etapu wymiany komunikatów, błędne przypisanie interfejsu do puli adresowej, brak trasy zwrotnej albo niezgodność ustawień pomiędzy routerem i serwerem. W efekcie komputer może mieć adres link-local, lecz nie uzyskać globalnego adresu IPv6, prefiksu delegowanego lub dodatkowych informacji konfiguracyjnych. Objawem bywa także działanie części usług przy jednoczesnym braku dostępu do wybranych zasobów.

DHCPv6 relay w kontekście technicznym i porównanie z innymi trybami

W jednej podsieci klient DHCPv6 może komunikować się z serwerem bez pośrednika. Gdy jednak serwer znajduje się w innym segmencie, router musi przekazać żądanie dalej. Właśnie wtedy używany jest DHCPv6 relay. Urządzenie pośredniczące nie przydziela adresu samodzielnie, lecz transportuje komunikat i przekazuje serwerowi informacje o interfejsie, z którego pochodzi zgłoszenie. Serwer na tej podstawie wybiera właściwy zakres, reguły dzierżawy oraz parametry przeznaczone dla danej podsieci.

Mechanizm ten należy odróżnić od autokonfiguracji SLAAC. Przy SLAAC host może utworzyć adres na podstawie ogłoszenia routera, bez klasycznej dzierżawy z serwera DHCPv6. DHCPv6 może jednak dostarczać dodatkowe dane, na przykład adresy serwerów DNS, a w niektórych sieciach odpowiada również za przydzielanie właściwych adresów. Jeżeli router wysyła ogłoszenia z nieodpowiednimi flagami, klient może oczekiwać konfiguracji z innego źródła niż to, które zostało faktycznie uruchomione. Powstaje wtedy wrażenie braku synchronizacji, mimo że pojedyncze elementy działają.

Istotne jest także rozróżnienie pomiędzy przydzielaniem adresu interfejsowi a delegowaniem prefiksu. Pierwszy mechanizm dotyczy konkretnego klienta, natomiast drugi pozwala routerowi otrzymać zakres IPv6 i wykorzystać go w dalszych segmentach. Błędne ustawienie jednego z tych trybów może powodować, że urządzenie otrzyma odpowiedź, lecz nie zastosuje jej zgodnie z oczekiwaniami. W diagnostyce trzeba więc ustalić, czy problem dotyczy adresu klienta, prefiksu, trasy, DNS, czy samego przekazywania komunikatów.

Warto również sprawdzić, czy filtracja ruchu nie blokuje komunikatów DHCPv6. Klient i serwer korzystają z określonych adresów multicast oraz portów UDP. Reguła zapory może przepuszczać zwykły ruch IPv6, a jednocześnie odrzucać komunikaty potrzebne do uzyskania dzierżawy. Podobny skutek może wywołać filtrowanie na przełączniku, izolacja portów, nieprawidłowa konfiguracja VLAN albo różne oznaczenia segmentów na routerze i serwerze.

Brak synchronizacji adresów przez DHCPv6 relay — typowe problemy

Jednym z częstych źródeł trudności jest wskazanie niewłaściwego interfejsu w konfiguracji relay. Jeżeli usługa nasłuchuje na innym segmencie niż ten, w którym znajdują się klienci, zapytania mogą nie zostać przechwycone. Zdarza się również, że relay jest uruchomiony na interfejsie tranzytowym, ale nie na interfejsie lokalnym. Wtedy serwer może działać prawidłowo, a mimo to nie otrzymywać zgłoszeń od urządzeń końcowych.

Drugą grupę stanowią błędy po stronie serwera. Pula może być przypisana do nieprawidłowego identyfikatora podsieci, zakres może być wyczerpany, a zasady wyboru puli mogą nie rozpoznawać informacji dołączonej przez relay. Warto porównać identyfikator interfejsu, prefiks oraz oczekiwany zakres z tym, co faktycznie znajduje się w odebranym komunikacie. Sama obecność wpisu konfiguracyjnego nie potwierdza jeszcze, że serwer dopasowuje klienta do właściwej puli.

Problemy mogą wynikać z trasowania. Odpowiedź serwera musi wrócić do urządzenia relay, a następnie do klienta. Brak trasy zwrotnej, błędna trasa domyślna lub filtracja ruchu na jednym z odcinków może sprawić, że zapytanie zostanie zauważone, lecz odpowiedź nie dotrze do odbiorcy. Niekiedy odpowiedź trafia do niewłaściwego interfejsu, szczególnie gdy urządzenie ma kilka aktywnych połączeń IPv6.

W praktyce spotyka się też niezgodność czasu dzierżawy, konflikt ręcznych i automatycznych ustawień adresowych oraz pozostałości po wcześniejszej konfiguracji. Klient może przechowywać stary adres, preferować nieaktualny serwer albo odrzucać odpowiedź z powodu niepasujących parametrów. W takim przypadku restart urządzenia może chwilowo zmienić objaw, ale nie usuwa przyczyny. Należy sprawdzić pełny cykl od wysłania zapytania do zastosowania odpowiedzi.

Diagnostyka braku synchronizacji adresów przez DHCPv6 relay

Diagnostykę najlepiej rozpocząć od ustalenia zakresu zjawiska. Należy sprawdzić, czy problem występuje na jednym urządzeniu, w całej podsieci, czy we wszystkich segmentach obsługiwanych przez ten sam router. Jeżeli tylko jeden host nie uzyskuje adresu, większe znaczenie mogą mieć ustawienia jego karty sieciowej, lokalna zapora, zapisany stan dzierżawy albo sterownik. Gdy problem obejmuje całą podsieć, należy skupić się na relay, VLAN, filtracji i konfiguracji serwera.

Pomocne jest porównanie parametrów interfejsu przed i po odświeżeniu konfiguracji. Trzeba zwrócić uwagę na adres link-local, adres globalny, prefiks, trasę domyślną, adresy DNS i czas dzierżawy. Sam brak adresu globalnego nie zawsze oznacza problem z DHCPv6, ponieważ część środowisk wykorzystuje SLAAC. Z kolei obecność adresu nie gwarantuje poprawnego działania, jeżeli brakuje trasy albo DNS.

Na urządzeniu relay oraz na serwerze warto przeanalizować dzienniki zdarzeń i przechwycić ruch na właściwych interfejsach. Należy potwierdzić kolejno: wysłanie zapytania przez klienta, odebranie go przez relay, przekazanie do serwera, wybór właściwej puli, wysłanie odpowiedzi oraz powrót odpowiedzi do klienta. Taka kolejność ogranicza ryzyko wprowadzania przypadkowych zmian. Jeżeli komunikat znika na konkretnym odcinku, dalsze sprawdzanie konfiguracji po drugiej stronie może nie przynieść rezultatu.

Po każdej korekcie trzeba ponowić test z wyczyszczonym stanem klienta, a następnie sprawdzić, czy przydzielony adres odpowiada właściwej podsieci. Należy unikać jednoczesnej zmiany kilku elementów, ponieważ utrudnia to ustalenie, która modyfikacja usunęła problem. Dobrą praktyką jest zapisanie aktualnej konfiguracji, czasu testu oraz wyników obserwacji.

Kiedy zgłosić brak synchronizacji adresów przez DHCPv6 relay do serwisu

Do serwisu warto zgłosić problem, gdy brak adresów powtarza się po restarcie, dotyczy wielu urządzeń albo powoduje niestabilny dostęp do zasobów IPv6. Szczególnie istotne jest to wtedy, gdy konfiguracja obejmuje kilka podsieci, wiele punktów dostępowych lub urządzenia pracujące w różnych trybach autokonfiguracji. W takiej sytuacji potrzebne może być sprawdzenie logów, reguł zapory, tablic routingu i ruchu między segmentami, a także uporządkowanie ustawień klientów.

Przed zgłoszeniem dobrze przygotować opis objawów, informację o tym, których urządzeń dotyczy problem, oraz wyniki podstawowego sprawdzenia adresu, trasy i DNS. Przydatne są również zrzuty konfiguracji relay i serwera, o ile nie zawierają danych poufnych. Pozwala to szybciej odróżnić błąd lokalny od problemu w całej sieci.

W Warszawie analizę takich usterek można zlecić firmie Warszawskie Pogotowie Komputerowe 24/7, przekazując opis segmentów sieci i moment pojawienia się problemu. Przed rozpoczęciem prac można ustalić zakres diagnostyki oraz sposób zabezpieczenia obecnej konfiguracji. Dzięki temu naprawa nie ogranicza się do ponownego uruchomienia urządzeń, lecz obejmuje znalezienie miejsca, w którym komunikacja DHCPv6 relay przestaje działać.