Konfiguracja i testowanie serwera RADIUS na Sophos Firewall

RADIUS łączy Sophos Firewall z Microsoft NPS, bramą MFA lub inną centralną usługą uwierzytelniania. Najpierw należy przygotować system zdalny i ścieżkę sieciową. Następnie tworzy się serwer w sekcji Authentication > Servers i przypisuje go w sekcji Authentication > Services wyłącznie do wymaganych usług logowania. Test odbiorczy obejmuje rzeczywiste logowanie oraz kontrolę użytkownika, grupy i reguły.

Do standardowego pobierania informacji o użytkownikach i grupach z domeny Windows często lepiej nadaje się bezpośrednia integracja Active Directory z Sophos Firewall. W nowoczesnych scenariuszach dostępu zdalnego właściwszą architekturą może być Microsoft Entra ID SSO dla Sophos Connect i VPN Portal. Jeśli zapora ma rozpoznawać już uwierzytelnionych użytkowników sieci Wi-Fi na podstawie przychodzących pakietów księgowania, obowiązuje inna procedura: konfiguracja RADIUS SSO z księgowaniem na Sophos Firewall.

Kiedy warto używać RADIUS

Zapora wysyła nazwę użytkownika i dane logowania do serwera RADIUS. Tam źródło użytkowników, Network Policy oraz ewentualnie MFA decydują o odpowiedzi Access-Accept lub Access-Reject. Dopiero potem lokalna grupa użytkowników, polityka VPN i reguły zapory określają, do których zasobów użytkownik uzyska dostęp.

W modelu RADIUS dane uwierzytelniania i autoryzacji są przechowywane w profilach użytkowników. Zezwolenie na korzystanie z usługi wymaga, aby żądanie odpowiadało przewidzianym atrybutom, na przykład adresowi IP klienta RADIUS wysyłającego żądanie. Shared Secret chroni przy tym hasła użytkowników; nie oznacza to szyfrowania całego transportu RADIUS.

Typowe zastosowania to:

• Remote Access VPN z Microsoft NPS lub usługą MFA;
• centralne logowanie do User Portal, VPN Portal lub Captive Portal;
• rozwiązanie przejściowe, gdy AD lub LDAP nie ma być połączone bezpośrednio z zaporą;
• wiele urządzeń sieciowych korzystających z tej samej usługi RADIUS.

Firmowa sieć WLAN zarządzana przez zaporę wymaga dodatkowo wyboru serwera w sekcji Wireless > Wireless settings. Pełną procedurę 802.1X opisano zatem w artykule Konfiguracja sieci WLAN bezpośrednio na Sophos Firewall.

W firmowej sieci WLAN zarządzanej przez SFOS komunikaty Accounting Request i Accounting Response zawierają informacje o sesji i księgowaniu. Są one odrębne od żądań, odpowiedzi i wyzwań Access używanych podczas logowania. Dla tej ścieżki bezprzewodowej Sophos dokumentuje obsługę księgowania na wszystkich urządzeniach obsługujących Wi-Fi; Wireless Network musi używać 802.1X, a księgowanie na serwerze RADIUS musi być włączone. Osobne porty i brak Interim Accounting Updates wyjaśnia podlinkowana instrukcja dotycząca sieci WLAN. Obsługa księgowania nie oznacza zapewnienia obsługi dodatkowego serwera RADIUS.

Zapisanie stanu początkowego i drogi powrotu

Przed zmianą usługi produkcyjnej należy w sekcji Authentication > Services zanotować dla każdego obszaru objętego zmianą:

• wybrane serwery i ich kolejność;
• stan opcji Set authentication methods same as firewall, Same as VPN lub Same as firewall;
• dotychczasową wartość Default group dla uwierzytelniania zapory;
• użytkownika, dla którego dotychczasowa metoda działa w sposób potwierdzony.

Podczas zmiany logowania administratorów należy pozostawić otwartą istniejącą sesję WebAdmin. Trzeba także sprawdzić lokalnego superadministratora przez dozwoloną już ścieżkę zarządzania. Wybór serwerów dla administratorów nie dotyczy tego superadministratora, jednak zewnętrznego logowania administracyjnego nigdy nie należy przełączać bez potwierdzonej lokalnej drogi powrotu.

Planowanie połączenia RADIUS

Role, ścieżka sieciowa i protokoły

W środowisku NPS zapora Sophos Firewall jest klientem RADIUS, a NPS — serwerem RADIUS. NPS sprawdza żądanie zgodnie z zasadami Connection Request Policy i Network Policy, a zazwyczaj także w Active Directory. O faktycznym dostępie nadal decyduje następnie reguła VPN lub reguła zapory.

Ogólna pomoc do SFOS 22 opisuje komunikację między zaporą a serwerem RADIUS z użyciem protokołu PAP. W sekcji Authentication > Services Sophos wymienia jednak dla połączeń L2TP i PPTP protokoły PAP, CHAP oraz MSCHAPv2. Taka macierz protokołów nie potwierdza dostępności tych samych metod dla IPsec ani innych ścieżek logowania. Dlatego usługę, klienta i metodę dozwoloną na serwerze RADIUS trzeba sprawdzić łącznie.

Klasyczny RADIUS korzysta z UDP, a udokumentowany formularz SFOS nie zawiera pól TLS ani certyfikatów. Ruch powinien zatem przebiegać kontrolowaną ścieżką wewnętrzną lub inną odpowiednio zabezpieczoną trasą. Silny Shared Secret nie zastępuje segmentacji ani ścisłego ograniczenia komunikacji między zaporą a serwerem RADIUS.

Starsze systemy zdalne mogą oczekiwać innych portów, na przykład 1645/UDP i 1646/UDP. Decydujące są porty rzeczywiście skonfigurowane po obu stronach, a nie te historyczne wartości.

Świadomy wybór przykładowych wartości

W tej instrukcji użyto następujących wartości:

• nazwa serwera NPS-HQ-RADIUS;
• adres IP serwera 10.20.30.15;
• port Authentication 1812;
• port Accounting 1813;
• Time-out 5 sekund;
• Domain name corp.example.

Wartości 10.20.30.15 i corp.example należy zastąpić adresem wewnętrznym oraz własną konwencją nazewnictwa. Pięć sekund to wartość początkowa do bezpośredniego sprawdzania hasła, a nie wartość domyślna Sophos. W przypadku powiadomienia push, połączenia telefonicznego lub zewnętrznego wyzwania wartość musi mieścić się w dozwolonym przez SFOS zakresie od 1 do 60 sekund oraz odpowiadać dostawcy i rzeczywistemu klientowi.

Shared secret jest wspólnym sekretem technicznym klienta i serwera RADIUS, a nie hasłem użytkownika. Sophos ogranicza jego długość do 48 znaków. Wartość należy przekazać oddzielnym, chronionym kanałem, bezpiecznie przechowywać i wprowadzić identycznie po obu stronach; sam protokół RADIUS nie przesyła sekretu przez sieć.

Dodawanie serwera RADIUS w sekcji Authentication

Ścieżka menu to Authentication > Servers.

1. Otwórz Add i w polu Server type wybierz RADIUS server.
2. W polu Server name wpisz na przykład NPS-HQ-RADIUS.
3. W polu Server IP wpisz wewnętrzny adres IP serwera RADIUS, w tym przykładzie 10.20.30.15.
4. Ustaw Authentication port zgodnie z konfiguracją serwera, zwykle na 1812.
5. Ustaw Time-out. W pierwszym bezpośrednim teście w tym przykładzie użyto 5 sekund.
6. Włącz Enable accounting tylko wtedy, gdy system zdalny ma przetwarzać dane księgowania. W takim przypadku uzgodnij także Accounting port, zwykle 1813.
7. Wprowadź Shared secret dokładnie w takiej postaci jak w systemie zdalnym.
8. Opcjonalnie ustaw Domain name. Przy równoległym użyciu AD i RADIUS spójna domena zapobiega utworzeniu różnych lokalnych obiektów użytkownika dla tej samej osoby. Po ustawieniu Domain name przy pierwszym logowaniu automatycznie tworzony jest lokalny wpis w formacie user@domainname. Bez tej wartości RADIUS tworzy użytkownika bez domeny, natomiast AD tworzy wpis z nazwą domeny; w ten sposób mogą powstać dwa lokalne wpisy dla tej samej osoby.
9. Group name attribute wprowadź tylko wtedy, gdy system zdalny w sposób potwierdzony zwraca oczekiwany atrybut. Pomoc Sophos określa go jako alias skonfigurowanej nazwy grupy, ale nie dokumentuje w tym miejscu ogólnego mapowania dowolnych atrybutów NPS na grupy lokalne.
10. Enable additional settings otwórz wyłącznie wtedy, gdy wymaga tego odpowiednia polityka. NAS-identifier identyfikuje serwer dostępu do sieci (Network Access Server), który wysyła żądanie, na przykład za pomocą nazwy FQDN. NAS-port-type określa typ portu używanego do logowania.
11. Uruchom Test connection z własnym użytkownikiem pilotażowym, a następnie wybierz Save.

Zapora obsługuje łącznie maksymalnie 20 skonfigurowanych serwerów uwierzytelniania. Dla każdej metody uwierzytelniania w sekcji Authentication > Services również można wybrać maksymalnie 20 serwerów.

Granice API w SFOS 22 i 23

Na potrzeby automatyzacji należy czytać dokumentację API oddzielnie od procedury WebAdmin. Poniższe uwagi opisują dokumentację, a nie zachowanie przetestowane tutaj na urządzeniu; nie stanowią gotowego do wykonania żądania Add/Edit.

• Przykład XML i tabela parametrów: Przykład zagnieżdża RADIUSServer w AuthenticationServer. Używa ServerAddress, Port i DomainName; tabela używa natomiast ServerIP, AuthenticationPort i domainName. Nie należy traktować tych zapisów jako zamiennych na podstawie domniemanej normalizacji tagów.
• Księgowanie: Komentarz w przykładzie mówi, aby uwzględnić AccountingPort w celu włączenia księgowania; bez tego parametru księgowanie jest wyłączone. Nie potwierdza to przetestowanego zachowania przy pominięciu pola podczas Edit ani częściowej aktualizacji. 2222 jest tylko wartością z przykładu XML, a nie domyślną wartością WebAdmin 1813; nie należy po cichu usuwać zamierzonego portu księgowania z generowanego XML.
• Niewyjaśnione wartości: Dla IntegrationType przykład pokazuje LooseIntegration/TightIntegration, ale tabela podaje Only '1' are allowed.; dla ServerType podaje Only '4' are allowed.. Nie należy z tego wyprowadzać mapowania wartości wyliczeniowych ani prawidłowych wartości żądania. Przy zmianach procedura WebAdmin opisana powyżej pozostaje bezpieczną drogą, dopóki nie zostanie wyjaśniona składnia API dla używanej wersji.
• Ograniczenia danych wejściowych API: ServerName jest ciągiem o długości maksymalnie 50 znaków; UTF-8 jest dozwolony, przecinki są zabronione. GroupNameAttribute i domainName są ciągami o długości maksymalnie 50 znaków każdy. AuthenticationPort jest liczbą całkowitą od 1 do 65535, z maksymalnie 5 cyframi i udokumentowaną wartością domyślną 1812. Tabela oznacza ServerIP, AuthenticationPort, SharedSecret i GroupNameAttribute jako Yes w kolumnie Mandatory; powyższa wskazówka WebAdmin dotycząca Group name attribute nie czyni pola API opcjonalnym. Są to ograniczenia z dokumentacji API, a nie nowo potwierdzone ograniczenia GUI.
• Delete i tożsamość: Również Delete dokumentuje ServerName jako identyfikator serwera z tymi samymi ograniczeniami nazwy. Przy zamierzonym usuwaniu należy użyć dokładnej istniejącej nazwy, a nie nazwy ponownie znormalizowanej. Choć Add/Edit i Delete podają dla ServerName oznaczenie Mandatory: No z pustą komórką Default, nie potwierdza to ani usuwania bez nazwy, ani usuwania z symbolami wieloznacznymi lub zbiorczego. Nadal wymagane są opisane niżej kontrole przypisań usług i bezpieczna procedura wycofania zmian.

Uwaga dotycząca API w SFOS 23: Dokumentacja API do dodawania i edytowania serwerów RADIUS dodaje opcjonalny parametr EmailAddressAttribute (ciąg znaków, maksymalnie 50 znaków) i uwzględnia go w przykładzie XML dla RADIUSServer. Nie podano wartości domyślnej. Ta uwaga dotyczy dokumentacji API, a nie dodatkowego pola w WebAdmin.

Odpowiedzi API podczas migracji z SFOS 22 do 23: W przypadku istniejących automatyzacji udokumentowane klasy odpowiedzi zmieniają się przy dodawaniu i edytowaniu serwerów RADIUS. Dokumentacja referencyjna API podaje następujące wartości w kolumnie Status:

Należy więc sprawdzić obsługę odpowiedzi oddzielnie dla każdej wersji SFOS i każdej operacji; logika oparta wyłącznie na dotychczasowych wartościach błędów nie wystarcza dla SFOS 23. Są to udokumentowane wartości statusu API, a nie dowód na kody statusu HTTP. Klucze JavaScript w kolumnie Message nie potwierdzają żadnego konkretnego tekstu odpowiedzi w czasie wykonywania. Tabele nie podają ani jednoznacznego przyporządkowania każdego starego błędu do nowego, ani reguły ponawiania prób.

Właściwa interpretacja księgowania

Po włączeniu Enable accounting zapora wysyła dla obsługiwanych typów klientów komunikat Accounting-Start podczas logowania, a przy zwykłym wylogowaniu — komunikat Accounting-Stop. Sophos wymienia następujące typy: Windows client, HTTP client, Linux client, Android, iOS, iOS HTTP client, Android HTTP client oraz API client. Żądania Start i Stop zawierają również czas odpowiednio logowania i wylogowania.

Podczas wyłączania lub ponownego uruchamiania zapory komunikat Accounting-Stop nie jest wysyłany. Jeśli sesja na serwerze RADIUS pozostaje otwarta, należy więc porównać czas restartu z logami RADIUS. Ta funkcja wychodzącego księgowania nie jest tym samym co przychodzące księgowanie RADIUS SSO, za pomocą którego zapora poznaje sesje z innych systemów.

Przygotowanie Microsoft NPS jako systemu zdalnego

W NPS zapora Sophos Firewall musi być skonfigurowana jako klient RADIUS. Minimalna lista kontroli w konsoli Network Policy Server wygląda następująco:

1. Otwórz RADIUS Clients and Servers > RADIUS Clients.
2. Utwórz New RADIUS Client z jednoznaczną wartością Friendly name, na przykład Sophos-Firewall-HQ.
3. W polu Address (IP or DNS) wpisz adres, z którego NPS rzeczywiście otrzymuje żądanie.
4. Jako Vendor wybierz zwykle RADIUS standard.
5. Wprowadź ten sam Shared secret co na zaporze.
6. W odpowiednich zasadach Connection Request Policy i Network Policy sprawdź warunki, decyzję o dostępie i metodę uwierzytelniania dozwoloną dla użytkownika pilotażowego.
7. Przygotuj Event Viewer i logi księgowania NPS do testów odbiorczych.

W przypadku klastrów HA, połączeń routowanych lub NAT nie wolno zgadywać adresu klienta NPS na podstawie topologii. Pierwszy test pokaże w NPS, jaki źródłowy adres IP rzeczywiście dociera do serwera. Jeśli żądanie w ogóle nie dociera albo NPS nie może go zweryfikować, należy najpierw sprawdzić routing, regułę zezwalającą na UDP, adres klienta RADIUS oraz Shared Secret. Zwykła odpowiedź Access-Reject wskazuje natomiast na problem z użytkownikiem, polityką lub metodą uwierzytelniania.

Przypisywanie RADIUS do właściwych usług

Po zapisaniu obiekt serwera nie jest jeszcze aktywny dla żadnego logowania. W SFOS 22 w sekcji Authentication > Services dostępne są następujące obszary:

• Firewall authentication methods;
• User portal authentication methods;
• VPN portal authentication methods;
• VPN (IPsec/dial-in/L2TP/PPTP) authentication methods;
• Administrator authentication methods;
• SSL VPN authentication methods.

Dla User Portal, VPN Portal, VPN oraz administratorów wybór serwera może być powiązany z uwierzytelnianiem zapory. SSL VPN udostępnia opcje Same as VPN i Same as firewall. Przed zmianą należy więc sprawdzić, czy dany obszar korzysta z własnej listy, czy z listy powiązanej.

W ograniczonym pilotażu dodaj NPS-HQ-RADIUS wyłącznie w wymaganym obszarze, ustaw go na zaplanowanej pozycji i wybierz Apply. Zapora odpytuje wiele serwerów w wyświetlonej kolejności. Jeśli ten sam użytkownik może już pomyślnie zalogować się za pośrednictwem wcześniejszego serwera, późniejsza polityka RADIUS MFA nie zostanie wywołana.

Captive Portal i Default Group

Captive Portal nie ma własnego obszaru w sekcji Authentication > Services. Korzysta z Firewall authentication methods. Ponadto przewidziana strefa musi mieć w sekcji Administration > Device access włączony dostęp Captive portal, a reguła zapory oparta na użytkownikach musi być odpowiednio skonfigurowana. Oficjalnym testem działania jest logowanie pod adresem https://<firewall-ip>:8090.

Wartość Default group w obszarze Firewall authentication methods ma znaczenie dla bezpieczeństwa. Po pierwszym pomyślnym zalogowaniu użytkownika zewnętrznego do usługi zapory w sekcji Authentication > Users tworzony jest jego obiekt. Jeśli nie ma odpowiedniego przypisania do grupy lokalnej, stosowana jest skonfigurowana Default Group. Przed pilotażem należy sprawdzić polityki tej grupy oraz wszystkie reguły, w których jest używana; grupa domyślna ze zbyt szerokimi uprawnieniami nie może niepostrzeżenie stać się mechanizmem zapasowym.

Ograniczenia challenge MFA zależnie od usługi

Zgodnie z pomocą SFOS 22 VPN Portal nie obsługuje uwierzytelniania RADIUS z MFA opartym na wyzwaniu. Pomyślny wynik Test connection nie potwierdza więc działania tej ścieżki portalowej. Mechanizmy push, połączenie telefoniczne, OTP i challenge również nie są zamienne: każdy przewidziany klient i każdą usługę trzeba testować oddzielnie. Dla lokalnego MFA na Sophos Firewall obowiązuje osobna procedura: Włączanie MFA dla Sophos Firewall WebAdmin, VPN Portal i Remote Access.

Testy odbiorcze konfiguracji

1. Połączenie i system zdalny

W sekcji Authentication > Servers otwórz NPS-HQ-RADIUS i uruchom Test connection z użytkownikiem pilotażowym. Jednocześnie sprawdź w NPS lub logach innego systemu zdalnego, czy:

• żądanie pochodzi z oczekiwanego adresu zapory;
• przetwarza je właściwa polityka;
• wynikiem jest Access-Accept;
• zwrócone zostały oczekiwane atrybuty.

Test potwierdza dane logowania i komunikację z serwerem. Nie potwierdza jeszcze kolejności usług, polityki VPN, grupy lokalnej ani reguły zapory.

2. Test rzeczywistej usługi

Następnie zaloguj tego samego użytkownika dokładnie przez docelową usługę. Dla Captive Portal, SSL VPN, IPsec, User Portal i WebAdmin obowiązują różne wymagania. W przypadku WebAdmin użytkownik zewnętrzny musi dodatkowo otrzymać przewidziany profil administratora; samo pomyślne uwierzytelnienie RADIUS nie nadaje uprawnień administracyjnych. Niewymagane ścieżki należy pozostawić bez zmian. W przypadku SSL VPN artykuł Konfiguracja Sophos Firewall SSL VPN Remote Access omawia politykę, Device Access i regułę zapory.

Po pomyślnym zalogowaniu sprawdź:

1. W sekcji Authentication > Users lokalnego użytkownika, domenę i faktyczną wartość Main Group.
2. W sekcji Current activities > Live users aktywną sesję; w razie potrzeby można ją zakończyć opcją Disconnect.
3. W prawym górnym rogu WebAdmin otwórz Log viewer, wybierz moduł Authentication i zastosuj filtr według użytkownika, źródłowego adresu IP oraz wąskiego przedziału czasu testu.
4. W logu ruchu sprawdź rzeczywisty identyfikator Firewall Rule ID oraz dostęp wyłącznie do dozwolonego zasobu docelowego.
5. Sprawdź przypadek negatywny z użytkownikiem spoza dozwolonej polityki NPS.

Jeśli logowanie działa, ale aplikacja jest nieosiągalna, należy sprawdzić strefę, pulę adresów IP VPN, grupę, pozycję reguły, NAT i routing. Artykuł Reguła Sophos Firewall nie jest stosowana: sprawdzanie przyczyn prowadzi przez diagnostykę tej ścieżki danych. Jeśli niejasne są już tożsamość, wybór usługi lub Main Group, pomocna będzie instrukcja Systematyczne rozwiązywanie błędów uwierzytelniania na Sophos Firewall.

Zawężanie przyczyn błędów na podstawie objawów

System zdalny nie otrzymuje żadnego żądania

Najpierw sprawdź wartości skonfigurowane w polach Server IP i Authentication port. Następnie skontroluj routing i zezwolenie na ruch UDP 1812 między adresem źródłowym używanym przez zaporę a adresem 10.20.30.15. Obiekt serwera RADIUS nie tworzy automatycznie reguły zapory dla ruchu tranzytowego.

Dla sieci bezprzewodowej zarządzanej przez SFOS Sophos dokumentuje ściśle ograniczony przypadek szczególny: jeśli serwer RADIUS jest połączony z zaporą przez tunel IPsec, dla sieci punktów dostępowych wymagane jest mapowanie Source NAT. Tłumaczy ono źródłowy adres IP dokładnie na ten adres IP zapory, przez który zapora dociera do serwera RADIUS. Pomoc dotycząca sieci bezprzewodowych wskazuje w tym celu konfigurację przez powłokę z użyciem sys-traffic-nat; nie podaje jednak w tym miejscu kompletnego polecenia gotowego do wykonania. Przed zmianą należy potwierdzić sieci punktów dostępowych, faktycznie używany adres źródłowy, adres zapory do translacji adresu źródłowego, tunel, drogę powrotną oraz logi RADIUS. Bez potwierdzonej składni konkretna konfiguracja w powłoce, wraz z kontrolą i wycofaniem zmian, wymaga ukierunkowanej eskalacji technicznej. Dla innych ścieżek RADIUS ta instrukcja dotycząca sieci bezprzewodowych nie potwierdza ogólnego wymogu stosowania NAT. Reguła LAN-do-VPN ani przykład trasy Forwarding-IPsec nie zastępują tej procedury obsługi ruchu generowanego przez system.

NAT ruchu systemowego dla potwierdzonej ścieżki Wireless-IPsec

Osobna pomoc CLI dla SFOS 22 i 23 dokumentuje poniższą składnię. Jest to wzorzec sprawdzony w dokumentacji, a nie test wykonany tutaj na urządzeniu. Uzupełnia opisany powyżej szczególny przypadek sieci bezprzewodowej; nie zastępuje sprawdzenia sieci AP ani planowania tunelu i drogi powrotnej.

⚠️ Przed zmianą: Zmiana NAT może przerwać uwierzytelnianie i inne usługi systemowe kierowane do tego samego celu. Przygotuj kopię zapasową, okno serwisowe i niezależny dostęp administracyjny. Cel RADIUS, zaobserwowany źródłowy adres IP, wymagany adres IP zapory, selektory IPsec lub trasa, droga powrotna i adres klienta NPS muszą być spójne. Jeśli ta ścieżka nie jest potwierdzona, nadal wymagana jest eskalacja techniczna.

Zaloguj się do Command-line console z uprawnieniami administracyjnymi i wybierz 4 – Device Console, a nie Advanced Shell. Najpierw zapisz istniejącą konfigurację za pomocą tego polecenia tylko do odczytu:

show advanced-firewall

Poniższy przykład IPv4 ma zastosowanie tylko wtedy, gdy 10.20.30.15 jest serwerem RADIUS, a 10.40.50.1 to dokładnie ten adres IP zapory, który przewidziano dla tej ścieżki. Zastąp oba adresy. 255.255.255.255 ogranicza cel do jednego hosta; szersza maska obejmuje dodatkowe cele. Polecenie nie ma filtra sieci źródłowej ani portu: nie wybiera wyłącznie jednej sieci AP lub UDP 1812. Bez interface mapowanie dotyczy ruchu do tego celu przez dowolny interfejs zapory. Zweryfikowany parametr interface <interface> może zawęzić zakres; nie zgaduj nazwy interfejsu. Nie nadpisuj ani nie usuwaj istniejących lub nakładających się mapowań bez ich sprawdzenia.

Dodaj mapowanie tylko wtedy, gdy świadomie zatwierdzono te skutki uboczne i odpowiednie mapowanie jeszcze nie istnieje:

set advanced-firewall sys-traffic-nat add destination 10.20.30.15 netmask 255.255.255.255 snatip 10.40.50.1
show advanced-firewall

Następnie na rzeczywistym kliencie testowym Wi-Fi sprawdź 802.1X, Accounting-Start oraz zwykłe wylogowanie z Accounting-Stop. Logi RADIUS muszą pokazywać oczekiwany źródłowy adres IP zapory, decyzję Access-Accept i otrzymane dane księgowania; sprawdź również tunel, ścieżkę odpowiedzi i inne usługi kierowane do tego samego celu. Samo wyświetlenie mapowania NAT nie dowodzi, że logowanie działa. W razie rozbieżności nie rozszerzaj reguł dostępu.

Aby wycofać wyłącznie nowo dodane przykładowe mapowanie, użyj tych samych dostosowanych wartości z delete. Jeśli dodano interface, zachowaj ten sam parametr również przy usuwaniu:

set advanced-firewall sys-traffic-nat delete destination 10.20.30.15 netmask 255.255.255.255 snatip 10.40.50.1
show advanced-firewall

Porównaj konfigurację z zapisanym stanem początkowym i ponownie sprawdź pierwotne uwierzytelnianie oraz objęte zmianą usługi systemowe. Błąd konsoli lub niejasny wpis jest powodem do zatrzymania się, a nie do wykonania ogólnego resetu.

NPS odpowiada Access-Reject

Odpowiedź Reject wskazuje, że ścieżka sieciowa i port zasadniczo działają. Należy teraz sprawdzić w NPS wartość Reason Code, właściwą zasadę Network Policy, stan użytkownika oraz dozwoloną metodę uwierzytelniania. Nieprawidłowy Shared Secret prowadzi natomiast do braku odpowiedzi albo odpowiedzi nieprawidłowej lub niemożliwej do zweryfikowania.

Test connection działa, ale logowanie do usługi nie

W sekcji Authentication > Services sprawdź właściwy obszar, przełącznik powiązania, kolejność serwerów oraz użycie opcji Apply. W przypadku Captive Portal sprawdź dodatkowo Device access i regułę zapory opartą na użytkownikach. Dla SSL VPN muszą być prawidłowe: Policy Member, dostęp SSL VPN w sekcji Device Access oraz wymagana reguła zapory.

Logowanie działa, ale stosowana jest niewłaściwa grupa

Sprawdź domenę i Main Group w sekcji Authentication > Users. Następnie porównaj Group name attribute, atrybuty zwracane przez system zdalny i Default group. Pomyślne uwierzytelnienie nie jest dowodem prawidłowej autoryzacji. Dlatego trzeba potwierdzić, że użytkownik użyty w teście negatywnym zostaje odrzucony przez warunek grupy lub polityki NPS.

Push lub challenge kończy się przekroczeniem limitu czasu

Użyj rzeczywistego klienta i porównaj znaczniki czasu w logach zapory, NPS oraz dostawcy MFA. Zwiększ limit czasu SFOS wyłącznie w zakresie od 1 do 60 sekund i wybierz najmniejszą wartość, która niezawodnie obejmuje zwykły przebieg wyzwania. Opartego na wyzwaniu RADIUS MFA w VPN Portal nie da się naprawić dłuższym limitem czasu, ponieważ Sophos nie obsługuje tej ścieżki.

Bezpieczne wycofanie zmian

Jeśli pilotaż się nie powiedzie, w odpowiednim obszarze sekcji Authentication > Services przywróć wcześniej zapisaną listę serwerów wraz z ich kolejnością, ustawienia przełączników powiązań oraz wartość Default group, a następnie wybierz Apply. Potem zaloguj użytkownika porównawczego przy użyciu pierwotnej metody i sprawdź lokalnego superadministratora.

Dopiero gdy wszystkie objęte zmianą usługi znów działają, usuń NPS-HQ-RADIUS z pozostałych przypisań usług. Obiekt serwera w sekcji Authentication > Servers należy usunąć tylko wtedy, gdy nie jest już planowane żadne jego użycie. W NPS przywróć klienta, politykę i Shared Secret do udokumentowanego stanu początkowego. Utworzone wcześniej lokalne obiekty użytkowników wymagają osobnej kontroli; ich usunięcie nie kończy automatycznie każdej istniejącej sesji, dlatego trzeba również sprawdzić Current activities > Live users.

Eksploatacja

RADIUS jest produkcyjną usługą tożsamości. Po zmianach w NPS, u dostawcy MFA, w AD lub kolejności usług test odbiorczy musi obejmować rzeczywiste logowanie pozytywne i negatywne. Shared Secret należy bezpiecznie udokumentować i rotować zgodnie z planem. Dla systemu zdalnego trzeba skonfigurować monitoring i określić czas przechowywania logów decyzji. Dzięki temu można ustalić, czy błąd wystąpił przed zaporą, podczas uwierzytelniania, czy dopiero na etapie autoryzacji.

FAQ