Serwer RADIUS odrzuca logowanie – brak komunikacji

Serwer RADIUS odrzucający logowanie (brak komunikacji) wskazuje na zablokowany port UDP 1812/1813 lub niepoprawny klucz współdzielony między klientem a serwerem.

Czym jest problem z odrzucaniem logowania przez serwer RADIUS

Komunikat „serwer RADIUS odrzuca logowanie – brak komunikacji” oznacza, że urządzenie próbujące uwierzytelnić użytkownika nie uzyskuje prawidłowej odpowiedzi z usługi RADIUS albo otrzymuje odpowiedź wskazującą na odrzucenie żądania. RADIUS służy do centralnego sprawdzania tożsamości użytkowników oraz, zależnie od konfiguracji, do przekazywania informacji o uprawnieniach i zasadach dostępu. Może obsługiwać między innymi logowanie do sieci bezprzewodowej, połączenia zdalne, urządzenia sieciowe, przełączniki, punkty dostępowe oraz bramy kontrolujące dostęp do zasobów.

Samo określenie „brak komunikacji” bywa mylące, ponieważ przyczyna nie zawsze polega na całkowitym przerwaniu połączenia. Pakiet może docierać do serwera, lecz odpowiedź może wracać do innego adresu, być filtrowana po drodze albo nie zostać zaakceptowana przez urządzenie klienckie. Również niezgodność ustawień uwierzytelniania może wyglądać jak problem z dostępnością usługi, zwłaszcza gdy interfejs administracyjny pokazuje wyłącznie ogólny komunikat o błędzie.

W typowym układzie występują trzy elementy: klient RADIUS, serwer RADIUS oraz użytkownik lub urządzenie przekazujące dane logowania. Klientem może być punkt dostępowy, przełącznik, koncentrator dostępu lub inny element infrastruktury sieciowej. Należy odróżnić adres klienta RADIUS od adresu użytkownika końcowego. Serwer podejmuje decyzję na podstawie źródła żądania, skonfigurowanego współdzielonego sekretu, wybranej metody uwierzytelniania oraz reguł zapisanych w lokalnej bazie lub zewnętrznym katalogu.

Kontekst techniczny i porównanie możliwych przyczyn - Serwer RADIUS odrzuca logowanie – brak komunikacji

RADIUS korzysta przede wszystkim z protokołu UDP, dlatego komunikacja nie przebiega tak samo jak w przypadku usług opartych na połączeniu TCP. Najczęściej żądania uwierzytelniania są kierowane na port UDP 1812, a komunikaty związane z rozliczaniem na port UDP 1813. W starszych konfiguracjach mogą występować inne porty, dlatego właściwe wartości powinny zostać sprawdzone w dokumentacji oraz w ustawieniach konkretnego urządzenia. Sam fakt, że port jest wpisany poprawnie, nie potwierdza jeszcze, że ruch jest przepuszczany przez zaporę.

Przydatne jest rozdzielenie problemu na kilka warstw:

• Warstwa sieciowa – sprawdzana jest trasa między klientem a serwerem, poprawność adresów, obecność odpowiednich tras oraz działanie interfejsów sieciowych.
• Warstwa filtrowania – weryfikowane są reguły zapory na serwerze, urządzeniach pośrednich i kliencie, a także profile sieciowe wpływające na obsługę ruchu UDP.
• Warstwa identyfikacji klienta – serwer musi rozpoznawać adres źródłowy urządzenia jako dozwolonego klienta RADIUS.
• Warstwa sekretu współdzielonego – klient i serwer muszą używać dokładnie tej samej wartości, z uwzględnieniem wielkości liter, znaków specjalnych i niewidocznych spacji.
• Warstwa uwierzytelniania – konieczna jest zgodność metody używanej przez klienta, serwer oraz bazę użytkowników.
• Warstwa polityk dostępu – poprawne połączenie z usługą nie gwarantuje przyznania dostępu, jeżeli konto jest zablokowane, wygasło albo nie spełnia warunków reguły.

Warto odróżnić odrzucenie wynikające z decyzji serwera od braku odpowiedzi. Odpowiedź typu Access-Reject wskazuje, że żądanie zostało obsłużone, ale nie spełniło warunków dostępu. Brak odpowiedzi, przekroczenie czasu oczekiwania lub wielokrotne retransmisje częściej kierują diagnostykę w stronę zapory, adresacji, routingu, niedostępnej usługi albo błędnego wskazania serwera. Z kolei komunikat dotyczący nieprawidłowego uwierzytelnienia może wskazywać na sekret, metodę EAP, certyfikat lub dane konta.

W środowisku wykorzystującym uwierzytelnianie certyfikatowe należy dodatkowo sprawdzić zaufanie do urzędu certyfikacji, daty ważności certyfikatów, nazwę serwera oraz zgodność ustawień po stronie klienta. Przy metodach opartych na katalogu użytkowników znaczenie może mieć dostępność usługi katalogowej, poprawny czas systemowy, format nazwy konta oraz przypisanie użytkownika do właściwej grupy. Różnica czasu między urządzeniami może powodować problemy z mechanizmami zabezpieczającymi, nawet jeśli podstawowa łączność sieciowa działa.

Typowe problemy i błędy konfiguracyjne - Serwer RADIUS odrzuca logowanie – brak komunikacji

Jednym z częstszych błędów jest wpisanie na serwerze niewłaściwego adresu klienta RADIUS. Jeżeli urządzenie wysyła żądanie z innego interfejsu niż zakładano, serwer może potraktować je jako nieznane i pominąć. Zdarza się również, że po zmianie adresacji, wymianie punktu dostępowego lub przywróceniu ustawień fabrycznych pozostaje stara definicja klienta. W takiej sytuacji należy porównać adres widoczny w logach serwera z adresem przypisanym w konfiguracji klienta.

Drugą grupę stanowią błędy sekretu współdzielonego. Wartość ustawiona po obu stronach musi być identyczna, a jej ponowne wpisanie ręcznie często pozwala wykluczyć przypadkowy znak lub spację. Nie powinno się jednak ograniczać diagnostyki wyłącznie do samego sekretu, ponieważ podobne objawy mogą wywołać także niezgodność portu, inny adres źródłowy, blokada pakietów lub niekompatybilny sposób uwierzytelniania.

Problemy mogą pojawić się po zmianie reguł zapory. Niekiedy odblokowany zostaje port dla ruchu wychodzącego, lecz nadal blokowany jest ruch przychodzący na serwerze. W innym przypadku pakiety są przepuszczane tylko z określonej podsieci, podczas gdy urządzenie korzysta z adresu należącego do innego zakresu. Trzeba również sprawdzić, czy filtr nie rozróżnia profilu sieci, interfejsu, kierunku ruchu lub adresu nadawcy.

Do typowych przyczyn należą także:

• zatrzymana usługa RADIUS albo usługa zależna od niej;
• zmieniony adres serwera w konfiguracji punktu dostępowego lub urządzenia sieciowego;
• skierowanie zapytań na niewłaściwy port;
• brak trasy zwrotnej do sieci, z której pochodzi klient;
• odrzucanie żądań przez regułę dostępu, filtr grupowy lub harmonogram;
• zablokowane, wygasłe albo nieaktywne konto użytkownika;
• niedostępna baza kont lub usługa katalogowa;
• niezgodna metoda EAP, certyfikat lub konfiguracja szyfrowania;
• różna interpretacja nazwy użytkownika, na przykład z domeną albo bez domeny;
• zmiana adresu interfejsu po restarcie lub przełączeniu trasy;
• odrzucenie żądania z powodu ograniczeń przypisanych do konkretnego klienta;
• niespójny czas systemowy utrudniający weryfikację certyfikatów.

Najwięcej informacji dostarczają logi serwera RADIUS, logi urządzenia klienckiego oraz przechwycenie ruchu wykonane w kontrolowany sposób. W logach należy szukać adresu źródłowego, nazwy klienta, rodzaju otrzymanego żądania, powodu odrzucenia i informacji o czasie obsługi. Jeżeli w logach serwera nie ma żadnego śladu próby logowania, warto najpierw sprawdzić adres docelowy, routing i filtrowanie. Jeżeli żądanie jest widoczne, ale kończy się odrzuceniem, dalsza analiza powinna objąć konto, polityki, sekret oraz metodę uwierzytelniania.

Kiedy trzeba oddać urządzenie do diagnozy - Serwer RADIUS odrzuca logowanie – brak komunikacji

Zgłoszenie do serwisu jest uzasadnione, gdy problem pojawia się po zmianie routera, punktu dostępowego, adresacji, zapory lub zasad dostępu i nie da się jednoznacznie ustalić, na którym etapie komunikacja przestaje działać. Warto przygotować opis momentu wystąpienia usterki, informację o tym, czy problem dotyczy wszystkich użytkowników czy tylko wybranych kont, oraz fragmenty logów pozbawione haseł i sekretów. Przydatne są również dane o adresach urządzeń, porcie używanym przez usługę i czasie wystąpienia błędu.

Nie należy wysyłać w zgłoszeniu jawnego sekretu współdzielonego, haseł ani prywatnych kluczy. Do analizy wystarczy informacja, że wartość została sprawdzona lub ponownie ustawiona po obu stronach. Jeżeli konieczne jest wykonanie zmian, dobrze jest wcześniej zapisać bieżącą konfigurację, aby można było odtworzyć stan sprzed modyfikacji i porównać zachowanie systemu po każdej zmianie.

Warszawskie Pogotowie Komputerowe 24/7 przyjmuje zgłoszenia dotyczące diagnostyki i napraw urządzeń komputerowych oraz sieciowych, a realizacja napraw zwykle mieści się w ciągu trzech dni roboczych. Przy problemie z RADIUS-em może zostać sprawdzona kolejność działania: dostępność serwera, przepływ pakietów UDP, rozpoznanie klienta, zgodność sekretu, działanie bazy użytkowników oraz reguły przyznawania dostępu. Takie uporządkowanie pozwala ograniczyć przypadkowe zmiany i szybciej wskazać rzeczywiste źródło odrzucania logowania.

Do serwisu warto zgłosić się także wtedy, gdy uwierzytelnianie działa tylko z jednego segmentu sieci, przerywa się po restarcie urządzenia, wymaga wielokrotnego wpisywania danych albo działa dla jednych metod dostępu, lecz nie dla innych. Objawy te mogą wskazywać na różnicę w adresie źródłowym, niepełną konfigurację kilku klientów, błędną regułę zapory lub niezgodność parametrów uwierzytelniania. Po usunięciu przyczyny powinno się wykonać test z kontem testowym, sprawdzić logi połączeń oraz potwierdzić, że dostęp jest przyznawany tylko zgodnie z zamierzoną polityką.