Który adres rejestrujesz jako klienta RADIUS w NPS?

Brama VPN, która przekazuje uwierzytelnianie do Windows NPS, potrzebuje po stronie NPS jednego obiektu, zanim zadziała jakakolwiek polityka użytkownika: wpisu klienta RADIUS dla bramy. Większość nieudanych prób rejestruje niewłaściwy adres, bo liczy się ten, którego brama używa na swojej ścieżce backendowej, a nie nazwa hosta wpisywana przez personel w aplikacji VPN. Jeśli ta wartość jest błędna, NPS po cichu odrzuca żądanie, co po stronie klienta wygląda jak błędne hasło. Który adres trafia do pola, rozstrzygają trzy warunki, więc ustal je przed otwarciem konsoli.

Zarejestruj bramę, nie laptopy ani pulę

Obiekt klienta RADIUS reprezentuje urządzenie dostępu sieciowego, które wysyła żądania uwierzytelniania. To brama VPN, a nie każdy laptop z klientem i nie zakres adresów przydzielanych wewnątrz tuneli.

Te adresy tuneli nigdy nie pojawiają się jako źródło żądania RADIUS, bo żądanie idzie własną ścieżką sieciową bramy. Zarejestrowanie wpisu puli klientów daje politykę, która nigdy nie może pasować, podczas gdy prawdziwe żądanie przychodzi z adresu, o którym NPS nigdy nie słyszał. To samo zamieszanie skłania ludzi do dodawania domowego IP każdego pracownika, co jest jednocześnie nie do utrzymania i błędne.

Trzy warunki rozstrzygają adres, który wpisujesz

Najpierw znajdź adres źródłowy, którego brama naprawdę używa wobec NPS. Brama z wieloma interfejsami często wysyła z interfejsu zarządzania lub backendu, a nie z publicznego nasłuchu VPN. Po drugie sprawdź, czy między nimi jest NAT: jeśli żądanie jest tłumaczone, NPS widzi adres przetłumaczony i to jest wartość do zarejestrowania. Po trzecie, jeśli dwie bramy dzielą rolę, każde źródło żądań potrzebuje własnego wpisu klienta, bo jeden obiekt z jednym adresem obejmuje tylko jedno z nich.

Wpis z dwoma końcami utrzymuje parę w porządku. Tabela poniżej używa adresów prywatnych jako ilustracji, więc zastąp je tymi, których twoja ścieżka naprawdę używa.

Potwierdź źródło, zamiast je zgadywać. Obserwuj dziennik NPS lub zapory podczas jednej próby albo przechwyć na hoście NPS za pomocą sudo tcpdump -ni any udp port 1812. Adres w tym przechwyceniu to jedyna obroniona odpowiedź dla wpisu klienta. Jeśli brama ma kilka możliwych źródeł, zarejestruj każde pod jego własną przyjazną nazwą.

Wspólny sekret jest wartością między bramą a NPS

Wspólny sekret uwierzytelnia relację urządzeń. To nie jest hasło użytkownika i nigdy nie jest udostępniane personelowi ani osadzane w profilach klientów.

Wybierz jedną wartość, wpisz ją w obu miejscach i przechowuj tam, gdzie leży kopia zapasowa konfiguracji bramy. Rozbieżność daje żądanie, które NPS odrzuca bez użytecznego błędu, a w dzienniku bramy nie da się tego odróżnić od nieosiągalnego serwera. Rotuj ją w okienku konserwacji i aktualizuj oba końce w tej samej zmianie.

Potwierdź jednym dozwolonym żądaniem

Użyj kontrolowanego konta i skoreluj jedną próbę po obu stronach. Na bramie potwierdź, że żądanie wyszło do zamierzonego serwera; w NPS, że przyszło od zarejestrowanego klienta i pasowało do oczekiwanej polityki żądań połączenia. Przekroczenie czasu i odrzucenie znaczą różne rzeczy, a traktowanie obu jako problemu z poświadczeniami marnuje następną godzinę. Następnie sprawdź konto poprawne, ale nieuprawnione, oraz błędne hasło, bo polityka przyjmująca wszystko przechodzi też pierwszy test.

Na końcu sprawdź, co brama robi ze zwróconą autoryzacją. Zarejestrowanie klienta RADIUS tylko pozwala urządzeniu uczestniczyć; nie daje każdej powstałej sesji dostępu do LAN.

Utrzymuj wynik diagnostyczny w ryzach: żadnych wspólnych sekretów, żadnych haseł użytkowników, żadnych pełnych ładunków pakietów w zgłoszeniu do pomocy. Jeśli projekt wymaga, aby serwer NPS czytał atrybuty katalogu, to uprawnienie jest osobnym zadaniem administracyjnym od rejestracji klienta, a gdy go brakuje, zawodzi inaczej.