Logowanie VPN zatrzymuje się po Access-Challenge RADIUS

Hasło jest poprawne, logowanie VPN mimo to się nie udaje, a serwer RADIUS być może zrobił dokładnie to, co mu nakazano. Brama prawdopodobnie otrzymała Access-Challenge, nie pokazała nic użytecznego, a następnie przekroczyła limit czasu albo potraktowała tę odpowiedź jako odmowę. Z perspektywy klienta wygląda to na błędne dane logowania lub uszkodzony tunel. Przyczyna zwykle tkwi w środku rozmowy, której nikt nie przechwycił.

Jedno logowanie, dwie wymiany z RADIUS

Gdy backend chce drugiego czynnika, nie odpowiada na pierwsze żądanie akceptacją ani odmową. Odpowiada kodem 11 i czeka na kolejną odpowiedź użytkownika, którą brama musi odesłać w żądaniu kontynuacji. Ta kontynuacja należy do tej samej rozmowy uwierzytelniania, a nie do nowej próby logowania.

W działającej konfiguracji użytkownik widzi drugie pytanie: najpierw hasło, potem kod jednorazowy, albo jedno połączone pytanie, jeśli operator je udokumentował. W zepsutej konfiguracji drugie pytanie nigdy się nie pojawia i logowanie po prostu się nie udaje.

To jest objaw, którego trzeba szukać, i łatwo go potwierdzić wyłącznie po stronie klienta: jeśli klient VPN prosi dokładnie o jeden sekret, a potem odrzuca hasło, o którym wiesz, że jest ważne, wymiana prawdopodobnie zakończyła się na wyzwaniu.

Co wyzwanie naprawdę niesie

Specyfikacja RADIUS opisuje kod 11 w sekcji 4.4 i dopuszcza dwa atrybuty, które mają tu znaczenie. Reply-Message zawiera tekst przeznaczony dla użytkownika, a State zawiera nieprzejrzystą wartość, którą serwer chce otrzymać z powrotem. NAS nie powinien interpretować State, tylko zwrócić go bez zmian.

Żądanie kontynuacji używa nowego Identifier i nowego Request Authenticator i musi nieść tę samą wartość State oraz odpowiedź użytkownika. Serwer dopasowuje je do oczekującego wyzwania właśnie przez ten State, dlatego brama, która regeneruje lub odrzuca atrybut, nie może dokończyć ceremonii. Response authenticator w każdej odpowiedzi również musi się zweryfikować, inaczej NAS powinien odrzucić pakiet.

Sekcja 4.4 dodaje szczegół, który wyjaśnia większość cichych awarii: NAS, który nie obsługuje wyzwań, traktuje Access-Challenge jako odmowę. Jeśli usługa VPN twojej bramy jest starsza od tego wsparcia albo je pomija, żądanie backendu o drugi czynnik staje się natychmiastowym „uwierzytelnianie nie powiodło się” bez żadnego pytania.

Gdzie gubi się żądanie łańcuchowe

Pierwszym podejrzanym jest ścieżka pytania, a nie dane logowania. Portal, który pokazuje pole OTP przy logowaniu przez web, nie robi tego automatycznie dla usługi VPN, a niektóre bramy przekazują wyzwanie tylko klientom, którzy zgłaszają tę możliwość. Przetestuj to samo konto w obu punktach wejścia; jeśli portal działa, a VPN nie, patrzysz na przekazanie, a nie na token.

Format danych wejściowych to drugi podejrzany. Sklejanie hasła i kodu bez udokumentowanego przez dostawcę separatora albo pozwolenie zapisanym danym na powtórzenie starego kodu kończy się niepowodzeniem wyglądającym identycznie jak błędne hasło. Używaj udokumentowanego przez operatora osobnego pytania lub formatu łączonego i nigdy nie wymyślaj separatora.

Istnieją defekty specyficzne dla wydania, ale lista poprawionych wersji sprzed lat nie jest diagnozą dla dzisiejszego wdrożenia. Czytaj informacje o wydaniu oprogramowania, które naprawdę uruchamiasz, i zachowaj zaobserwowany etap wymiany jako dowód.

Prześledź jedną próbę od początku do końca

Odtwórz ją raz z włączonym debugowaniem po stronie serwera i trzymaj każdą inną sesję poza oknem przechwytywania:

$ sudo radsniff -i eth0 -x -f 'udp port 1812'
$ sudo freeradius -X
$ radtest alice 'password' 127.0.0.1 0 testing123

W danych wyjściowych szukaj kształtu rozmowy, a nie pojedynczej linii. Pierwszy Access-Request z Identifier 3, Access-Challenge niosący State, potem drugi Access-Request z Identifier 4, który powtarza ten State i zawiera odpowiedź użytkownika. Jeśli brakuje drugiego żądania, brama nigdy nie podjęła kontynuacji. Jeśli przychodzi bez State, serwer nie może dopasować go do oczekującego wyzwania i zwykle je odrzuci.

Udostępniając ślad, zamazuj dane logowania, tokeny i zbędne dane tożsamości, a zdarzenia koreluj z jednej próby, zamiast mieszać powtórzenia z kilku kart przeglądarki. Znaczniki czasu są tu twoim przyjacielem; wyzwanie, które przychodzi po tym, jak klient się poddał, wygląda dla użytkownika jak odmowa, a w logu jak wolna odpowiedź.

Pożądany stan końcowy to zakończona, autoryzowana rozmowa, po której następuje zamierzony dostęp do usługi. Odpowiedź przychodząca z serwera RADIUS dowodzi znacznie mniej.