Bezpieczne tworzenie i obsługa kont gości w Sophos Firewall

Funkcja Guest users umożliwia tworzenie w Sophos Firewall tymczasowych kont dla osób, które nie mają zwykłego konta użytkownika. Sprawdza się to na przykład w przypadku gości, zewnętrznych techników lub uczestników szkoleń, którzy logują się przez Captive Portal i powinni otrzymać wyłącznie jasno ograniczony dostęp do Internetu.

Bezpieczna skrócona procedura wygląda następująco:

1. Przygotować restrykcyjną grupę gości z wymaganymi zasadami dostępu.
2. W Authentication > Guest user settings ustawić prefiks, grupę, hasło i czyszczenie kont.
3. Zdecydować, czy administrator tworzy pojedyncze lub wiele kont, czy rzeczywiście potrzebna jest samodzielna rejestracja przez SMS.
4. Ustawić ważność na Immediately lub After first login i bezpiecznie przekazać dane logowania.
5. Przetestować Captive Portal, regułę użytkownika, separację sieci oraz jeden dozwolony i jeden zablokowany cel.
6. Po wygaśnięciu wyłączyć lub usunąć konto, a istniejące sesje i logi sprawdzić osobno.

⚠️ Konto gościa jest tylko tożsamością. Nie zapewnia segmentacji sieci i nie otwiera ścieżki danych. Goście powinni znajdować się w osobnej strefie lub VLAN-ie i korzystać z wąskiej, logowanej reguły firewall. Dane logowania, wydruki i wiadomości SMS należy traktować jak hasła.

Rozróżnienie kont gości, voucherów i zwykłych użytkowników

Konto gościa jest tymczasowym lokalnym rekordem użytkownika. Firewall generuje Username i hasło na podstawie globalnych ustawień kont gości. Po zalogowaniu może przypisać ruch do tej tożsamości i zastosować zasady wybranej grupy.

Pozostałe modele dostępu służą innym celom:

• Zwykły użytkownik lokalny lub zewnętrzny: odpowiedni dla osób powracających, mających stałe konto, centralne źródło użytkowników lub MFA. Tworzenie i zarządzanie zwykłymi lokalnymi użytkownikami wyjaśnia model utrzymywany bezpośrednio na firewallu.
• Guest user: odpowiedni dla osoby potrzebującej dostępu tymczasowego, z własnym kontem, indywidualną ważnością i opcjonalną kontrolą wykorzystania.
• Hotspot Voucher: kod do Wireless Hotspot. Ważność vouchera, czas online, ilość danych i liczba urządzeń są zarządzane w modelu Hotspot. Konfigurację opisano w Konfiguracja Hotspot Sophos Firewall z voucherem lub hasłem dziennym.
• Clientless User: przypisuje stały adres IP do urządzenia bez logowania się konkretnej osoby. Procedurę opisano w Konfiguracja Clientless Users w Sophos Firewall.

Konta gości nie są przeznaczone do Remote Access SSL VPN ani IPsec Remote Access. Aktualne zasady SSL VPN nie zezwalają na Guest users ani Guest groups jako Policy members. Do Remote Access należy użyć zwykłego użytkownika z odpowiedniego lokalnego lub zewnętrznego źródła. Pełną konfigurację VPN opisano w Konfiguracja SSL VPN Remote Access.

Aktualna strona pomocy SFOS 23 Edit guest user nadal wymienia pola SSL VPN i IPsec Remote Access. Jednak strony SFOS 23 dotyczące zasad SSL VPN i ustawień IPsec wyraźnie wykluczają Guest users i Guest groups z tych dwóch metod dostępu zdalnego. To nierozstrzygnięta sprzeczność dokumentacji w obrębie tej samej wersji, a nie potwierdzona zmiana między wersjami. Pola te nie dowodzą obsługi VPN dla gości; dla SSL VPN i IPsec nadal zalecany jest zwykły użytkownik. Wykluczenia te nie określają uprawnień gości do Clientless SSL VPN, L2TP ani PPTP; te części strony Edit pozostają niewyjaśnione.

Ta sama sprzeczność występuje na stronach pomocy SFOS 22. Strony Edit obu wersji opisują również zakładki przeglądarki dla Clientless SSL VPN policy oraz opcjonalnie przypisywane adresy IP dla IPsec remote access, L2TP i PPTP. Opisy tych pól nie uprawniają do włączania tych metod dla gości. Na potrzeby opisanego tu dostępu do Internetu nie dodaje się uprawnień dostępu zdalnego. Odrębne potrzeby związane z VPN realizuje się przy użyciu zwykłego użytkownika i odpowiedniej procedury VPN; niewyjaśnionych opcji dla gości nie włącza się eksperymentalnie w środowisku produkcyjnym.

Przykładowa konfiguracja i wymagania

Poniższy przykład wykorzystuje osobną sieć dla gości i konto na jednodniową wizytę:

• Strefa: Guest
• Sieć: 10.30.40.0/24
• Nazwa portalu: login.example.com
• Grupa gości: Guest_Internet
• Username prefix: guest-
• Password length: 16
• Simultaneous sign-ins: 1
• Validity period: 1 day
• Validity start: After first login

10.30.40.0/24 to prywatna sieć przykładowa, którą należy zastąpić rzeczywistą siecią dla gości. login.example.com jest nazwą dokumentacyjną. Należy ją zastąpić nazwą FQDN, która z sieci gości rozwiązuje się na osiągalny adres firewalla i jest objęta certyfikatem portalu. Grupa otrzymuje tylko zasady faktycznie potrzebne dla tego dostępu gościnnego.

Przed utworzeniem kont muszą być spełnione następujące warunki:

1. Sieć gości, DHCP, DNS, routing i NAT sprawdzono przy użyciu ściśle ograniczonej tymczasowej reguły testowej. Regułę tę należy usunąć przed testem uwierzytelniania; osobna reguła DNS może zezwalać wyłącznie na wymagany ruch do resolvera.
2. Dostęp do sieci wewnętrznych i usług zarządzania ze strefy gości jest zablokowany.
3. Captive Portal jest osiągalny tylko z przewidzianej strefy.
4. Osobna grupa obejmuje Access Time, limity, Traffic Shaping i Sign-in Restriction.
5. Dostęp administracyjny i niezależna ścieżka zarządzania pozostają dostępne podczas testu.
6. Zasady wydawania, wygasania, unieważniania i przechowywania danych dostępowych gości są ustalone organizacyjnie.

Konfiguracja globalnych ustawień kont gości

Przed utworzeniem pierwszego konta należy otworzyć:

Authentication > Guest user settings

Te wartości są szablonem dla nowo tworzonych kont gości. Dlatego zmianę szablonu należy najpierw sprawdzić na koncie testowym.

Bezpieczny wybór General settings

W sekcji Guest user general settings ustawia się następujące pola:

1. Username prefix: w przykładzie guest-. Neutralny prefiks jest lepszy niż nazwa firmy, lokalizacji lub klienta, która niepotrzebnie ujawnia informacje.
2. Group: wybrać Guest_Internet. Użytkownicy goście dziedziczą zasady tej grupy.
3. Password length: w przykładzie 16. Sophos dopuszcza w Captive Portal maksymalnie po 50 znaków dla nazwy użytkownika i hasła. Długość powinna zapewniać odpowiedni poziom bezpieczeństwa i niezawodne użycie w przewidzianym sposobie przekazania.
4. Password complexity: wybrać najsilniejszą opcję zgodną z procesem wydawania danych i logowania.
5. Disclaimer: ten tekst jest drukowany pod wygenerowanymi danymi logowania. Należy podać krótkie warunki korzystania, odpowiedzialność i kontakt. Rzeczywiste dane logowania ani wewnętrzne szczegóły techniczne nie powinny się w nim znaleźć. Konfiguracja komunikatu logowania i wiadomości w Sophos Firewall wyjaśnia globalne zarządzanie tekstami administracyjnymi, uwierzytelniania, SMTP i SMS.
6. Auto purge on expiry: włączyć tylko wtedy, gdy wygasłe rekordy użytkowników mają być automatycznie usuwane, a wymagane dowody operacyjne są zachowywane w inny sposób.
7. Zapisać przyciskiem Apply.

Auto purge on expiry usuwa po wygaśnięciu szczegóły konta gościa, ale nie powiązane logi. Ma to znaczenie dla ochrony danych i diagnostyki: czyszczenie kont i przechowywanie logów to dwa odrębne procesy.

Bezpieczne zarządzanie grupami użytkowników w Sophos Firewall wyjaśnia współdziałanie zasad grupowych, Main Group i wyjątków użytkownika. W przypadku gości nie należy używać grupy domyślnej jedynie dla wygody. Osobna restrykcyjna grupa ułatwia zrozumienie działania i wycofanie zmian.

Przy automatyzacji przez API: Dokumentacja API dla SFOS 22 i 23 ogranicza UserNamePrefix do 10 znaków; guest- mieści się w tym limicie. Jest to udokumentowane ograniczenie API, a nie dowód sposobu walidacji w każdej wersji interfejsu graficznego. Zalecana długość hasła pozostaje 16. Przed zmianą odczytać bieżące ustawienia i na jednym koncie pilotażowym sprawdzić rzeczywiście wygenerowane dane logowania, grupę i ważność.

Przykłady API nie są w pełni spójne: PasswordComplexity używa wartości symbolicznych w przykładzie, ale definicji typu całkowitego w tabeli atrybutów; AutoPurgeOnExpiry podaje Enable/Disable w przykładzie, a tylko Enable w tabeli. Nie zgadywać tych wartości. Przed zapisem przez API ustalić schemat obsługiwany przez konkretną wersję firewalla; w przeciwnym razie użyć udokumentowanych pól interfejsu graficznego. Wartości domyślne i ograniczenia liczby cyfr w API nie dowodzą uniwersalnych wartości domyślnych ani granic ważności w interfejsie graficznym.

Samodzielna rejestracja tylko przy rzeczywistej potrzebie

W Guest user registration settings można włączyć samodzielną rejestrację. Jest ona bardziej złożona niż kontrolowane wydawanie kont przez administratora lub recepcję i wymaga niezawodnego procesu SMS:

• Enable guest users registration: włączyć tylko wtedy, gdy goście mają rejestrować się samodzielnie.
• SMS gateway: wybrać wcześniej przetestowanego dostawcę.
• Guest username: użyć numeru telefonu komórkowego lub wygenerować nazwę z Username prefix.
• User validity: ustawić maksymalną ważność samodzielnie zarejestrowanych kont w dniach.
• Default country code: dobrać do rzeczywistej grupy użytkowników. Ta wartość domyślna jest wyświetlana przy polu numeru telefonu komórkowego na stronie rejestracji gości.
• CAPTCHA verification: pozostawić włączone, aby utrudnić automatyczne rejestracje.
• Zapisać przyciskiem Apply.

Firewall obsługuje bramki SMS działające przez HTTP i HTTPS. Należy preferować HTTPS, aby dane logowania i parametry dostawcy nie były przesyłane bez szyfrowania. Adres URL, metoda HTTP, format numeru telefonu, parametry żądania i format odpowiedzi muszą dokładnie odpowiadać dokumentacji używanego dostawcy SMS. Przykładowych adresów URL z instrukcji nie należy kopiować do środowiska produkcyjnego.

Test connection wysyła wiadomość testową na numer telefonu. Według Sophos test może nie powieść się dla prywatnej bramki SMS z wewnętrznym adresem IP, mimo że rzeczywisty proces działa. Nie należy wtedy zakładać sukcesu, lecz sprawdzić pełną rejestrację za pomocą urządzenia mobilnego, logu dostawcy i faktycznie odebranej wiadomości SMS.

Prawidłowe mapowanie parametrów bramki SMS

W Authentication > Guest user settings > SMS gateway > Add należy podać Name, URL, HTTP method jako Get lub Post, Cell number format oraz, w razie potrzeby, Use country code with mobile phone number i Number prefix. Pomoc interfejsu graficznego opisuje Number prefix jako dopuszczający znaki alfanumeryczne i specjalne ASCII. Nie jest to ogólna gwarancja dla API: pole CellNumberPreFix wyraźnie wyklucza przecinki.

Każdy parametr żądania ma pola Name i Value; SFOS zastępuje {mobileno} i {msg} numerem telefonu i treścią wiadomości. Dla odpowiedzi należy przypisać Parameter index i Name do Response format. Nazwy parametrów nie są narzucone przez SFOS i muszą dokładnie odpowiadać wymaganiom dostawcy. Poniższy schemat używa wyłącznie zarezerwowanych wartości przykładowych:

URL: https://sms.example.net/send
HTTP method: Post
mobile = {mobileno}
message = {msg}
Response format: status={0}&message={1}
0 = status; 1 = message

sms.example.net, mobile, message i status należy zastąpić wartościami rzeczywistego dostawcy SMS. Get wysyła żądanie do wskazanego zasobu; Post przesyła dane do przetworzenia. Metodę wybiera się zgodnie z API dostawcy, a nie ogólną preferencją. Znaki specjalne w wymaganych przez dostawcę wartościach URL muszą być zakodowane procentowo, na przykład @ jako %40. Dane logowania w adresie URL lub żądaniu są sekretami i nie powinny trafiać do zrzutów ekranu, zgłoszeń ani logów. Jeśli dostawca ich wymaga, należy używać wyłącznie HTTPS i dokumentować termin ważności.

Response format określa jedynie sposób odczytania odpowiedzi. W przykładzie z dokumentacji odpowiedź taka jak status=302&message=Limit Exceeded oznacza przekroczenie limitu, a nie pomyślne wysłanie SMS-a. Status powodzenia lub błędu należy sprawdzić w dokumentacji dostawcy i potwierdzić rzeczywisty odbiór. Najpierw zapisać bramkę przyciskiem Save, a następnie wykonać Test connection z kontrolowanym numerem telefonu.

Ograniczenia API i zduplikowane parametry: Dla SFOS 22 i 23 API dokumentuje maksymalnie 100 znaków bez przecinka dla Name bramki oraz maksymalnie 255 znaków dla ResponseFormat. Ograniczenia API nie określają automatycznie limitów interfejsu graficznego. Zduplikowane wpisy ParameterName i ParameterValue na listach żądania i odpowiedzi nie są ignorowane. Sprawdzić każdą parę nazwa/wartość pod kątem przypadkowych duplikatów; celowe powtórzenia zachować tylko zgodnie z wymaganiami dostawcy. Nie określa to sposobu ich interpretacji przez dostawcę ani nie oznacza automatycznego wysłania wielu SMS-ów. Tabela URL API wymienia również FTP i adresy IPv4, podczas gdy pomoc interfejsu graficznego opisuje HTTP/HTTPS. Nie rozszerza to tej instrukcji o FTP ani transmisję bez szyfrowania: dla sekretów używać wyłącznie HTTPS. Status operacji API 200 nie zastępuje rzeczywistego odbioru SMS-a ani pełnego testu rejestracji. Użyć kontrolowanego numeru testowego za zgodą odbiorcy; możliwe są opłaty dostawcy.

W Administration > Messages > SMS customization należy wybrać Edit, wprowadzić wiadomość zgodną z szablonem akceptowanym przez dostawcę i zapisać ją przyciskiem Apply. W tekście wiadomości można użyć {username}, {password} i {expirydate}. Jest to osobny krok zapisu wiadomości. Niezgodny szablon może spowodować odrzucenie wiadomości przez dostawcę i niepowodzenie Test connection.

Test dostawcy jest tylko częściową kontrolą: w pilotażu gość łączy się z siecią Wi-Fi dla gości, otwiera Register for internet access, wypełnia formularz, rozwiązuje CAPTCHA i zapisuje przyciskiem Save. Po udanej rejestracji pojawia się strona logowania. Faktycznie odebrany SMS musi zawierać Username i hasło; gość loguje się za pomocą tych danych. Rekord musi być następnie widoczny w Authentication > Guest users, a logowanie w Current activities > Live users. Ruch musi zostać zapisany z oczekiwanym użytkownikiem i Firewall Rule ID. Szeroka reguła Any nie zastępuje tego potwierdzenia.

Jeśli brakuje bramki SMS, odpowiedzialnej osoby lub właściwej ochrony strony rejestracji, samodzielna rejestracja pozostaje wyłączona. Wyznaczona osoba tworzy wtedy konta w kontrolowany sposób.

Tworzenie pojedynczych lub wielu kont gości

Tworzenie pojedynczego konta z nazwą i adresem e-mail

Dla konkretnego gościa należy otworzyć Authentication > Guest users > Add single:

1. W polu Name wpisać na przykład Visitor Zurich 2026-08-11. To pole jest nazwą rekordu, a nie nazwą Username wygenerowaną później.
2. Wprowadzić adres e-mail osoby odpowiedzialnej. To pole nie wysyła danych logowania; w tym celu Sophos dokumentuje Add and print lub SMS.
3. Ustawić Validity period na wymagany okres, w przykładzie 1 day.
4. Świadomie wybrać Validity start.
5. Zapisać przyciskiem Add albo zapisać i wydrukować dane logowania przez Add and print.

Immediately rozpoczyna ważność w chwili utworzenia. Pasuje to, gdy dane logowania są od razu przekazywane i używane. After first login rozpoczyna okres po pierwszym udanym logowaniu. Ten wariant jest zwykle lepszy dla kont przygotowywanych z wyprzedzeniem, ponieważ ważność nie upływa jeszcze przed przybyciem gościa.

Po utworzeniu lista pokazuje wygenerowany Username. Podczas przekazywania danych nie należy mylić nazwy rekordu z Username.

Generowanie wielu kont na wydarzenie

W Authentication > Guest users > Add multiple ustawia się Number of users, Validity period i Validity start. Add tworzy konta bez drukowania. Add and print generuje konta i odpowiadające im wydruki.

Przy tworzeniu kont przez API: SFOS 22 i 23 dokumentują zakres 1–100 dla NoOfUsers na żądanie. Nie jest to zweryfikowane maksimum dla Add multiple w interfejsie graficznym. Większe operacje wydawania kont podzielić na świadomie dobrane partie API. Wcześniej zapisać planowaną liczbę, globalny szablon i początek ważności oraz sprawdzić pojedyncze konto. Po każdym żądaniu porównać rzeczywiście utworzone nazwy użytkowników z wydrukami; w razie niejasnej odpowiedzi najpierw odczytać listę kont zamiast powtarzać w ciemno żądanie tworzenia. Przykład API pomija NoOfUsers, mimo że tabela oznacza je jako obowiązkowe, i nie wyjaśnia wartości 1/2/3 dla Expirty Period type. Nie wyprowadzać z niego kompletnego żądania ani mapowania wartości wygaśnięcia; najpierw ustalić schemat odpowiedni dla wersji. Nie interpretować Name jako Username; wygenerowane dane logowania wydawać w sposób kontrolowany.

Wiele kont należy generować tylko na konkretne wydarzenie. Wydruki są liczone, bezpiecznie przechowywane i przekazywane osobie odpowiedzialnej. Niewydane lub wygasłe konta są wyłączane albo usuwane. Duży zapas nieprzypisanych danych logowania osłabia ograniczenie techniczne.

Sprawdzanie grupy, zasad i ograniczeń logowania

Nowe konto gościa dziedziczy najpierw grupę wybraną w Guest user settings. W Authentication > Guest users > Edit można sprawdzić nazwę, hasło, numer telefonu, adres e-mail, grupę i poszczególne zasady, a następnie zapisać je przyciskiem Save.

Zasady przypisane bezpośrednio użytkownikowi mają pierwszeństwo przed zasadami grupowymi. Indywidualne ustawienie nadrzędne ma więc sens tylko jako udokumentowany wyjątek. W jednolitym modelu dostępu gościnnego Access Time, Surfing Quota, Network Traffic, Traffic Shaping i Sign-in Restriction pozostają zwykle zebrane w Guest_Internet. Traffic shaping przypisuje użytkownikowi zasadę QoS, która może określać powiązanie zasad, priorytet oraz osobne limity wysyłania i pobierania.

Dla przykładu obowiązują następujące ograniczenia:

• Sign-in restriction: User group nodes dziedziczy ograniczenie grupy gości. Dla indywidualnego wyjątku należy ograniczyć Selected nodes lub Node range do rzeczywiście potrzebnych źródeł. Any node pasuje tylko wtedy, gdy logowanie ze wszystkich sieci jest zamierzone i oddzielnie zabezpieczone.
• Simultaneous sign-ins: 1, dopóki konto gościa nie zostanie wyraźnie przeznaczone do używania na wielu urządzeniach. Pole ogranicza liczbę jednoczesnych sesji; można odziedziczyć wartość globalną lub ustawić indywidualną.
• MAC binding: zwykle wyłączone dla zmieniających się gości. Firewall i tak nie wiąże użytkowników Remote Access VPN za pomocą adresów MAC. Po włączeniu logowanie jest dozwolone tylko z określonych urządzeń; ich adresy MAC trzeba wpisać w MAC address list.
• Quarantine digest: włączyć tylko wtedy, gdy konto rzeczywiście korzysta z Mail Protection i określonego procesu kwarantanny. Digest wysyła listę zatrzymanych wiadomości e-mail do skrzynki odbiorczej użytkownika.
• Remote access policies: nie planować jako dostępu VPN dla użytkowników gości.

Ważność konta służy innemu celowi niż zasady dotyczące czasu i wykorzystania:

• Validity period określa, jak długo można używać konta gościa.
• Access Time zezwala na dostęp do Internetu lub go blokuje w powtarzalnych przedziałach czasu.
• Surfing Quota i Network Traffic Quota ograniczają czas online lub ilość danych.
• Reguła firewall określa, które strefy, cele i usługi są w ogóle osiągalne.

Warstwy te nie zastępują się wzajemnie. Ważne konto nie może uzyskać dostępu do serwera wewnętrznego, jeśli reguła firewall nie zezwala na to wyraźnie.

Połączenie Captive Portal ze ścieżką danych

Użytkownicy goście zazwyczaj logują się przez Captive Portal. Device Access, DNS, HTTPS, reguła użytkownika i wybrana metoda uwierzytelniania muszą więc do siebie pasować. Sam portal nie zapewnia jeszcze dostępu do Internetu.

Oddzielna konfiguracja DNS i reguły użytkownika

W Rules and policies > Firewall rules wybrać odpowiedni protokół IP oraz Add firewall rule > New firewall rule. Przykładowa instrukcja SMS wykorzystuje dwie reguły z WiFi do WAN: jedną dla DNS, drugą dla ruchu użytkowników z Any. W rzeczywistej sieci gości należy zawęzić te szerokie wartości przykładowe:

1. Ustawić regułę DNS na Action: Accept, Source zones: Guest oraz sieć 10.30.40.0/24 w Source networks and devices. W Destination networks wybrać wyłącznie przewidziane resolvery, a w Services tylko DNS. Destination zones musi odpowiadać rzeczywistej lokalizacji resolverów; WAN jest poprawne tylko dla resolverów zewnętrznych. To niezbędne rozwiązywanie nazw nie wymaga wcześniejszego logowania użytkownika.
2. Regułę użytkownika również ustawić na Action: Accept, tę samą strefę gości i sieć źródłową, Destination zones: WAN oraz wyłącznie przewidziane cele i usługi internetowe. Włączyć Match known users, wybrać Guest_Internet w Users or groups i włączyć Use web authentication for unknown users. Strony pomocy SMS dla SFOS 22 i 23 nadal nazywają tę ostatnią opcję Show captive portal to unknown users; aktualne strony dotyczące reguł firewall obu wersji używają Use web authentication for unknown users. Różnica nazw nie dowodzi odmiennego działania.
3. Włączyć Log firewall traffic i zapisać każdą regułę przyciskiem Save. Sprawdzić ich położenie, aby wcześniejsza szeroka reguła zezwalająca nie omijała kontroli użytkownika, a istniejące blokady sieci wewnętrznych i usług zarządzania pozostały skuteczne. NAT i dostęp do portalu nadal sprawdza się osobno. Przed zalogowaniem połączenie nie może mieć swobodnego dostępu do Internetu poza wyraźnie wymaganymi usługami dostępnymi przed uwierzytelnieniem.

Guest i 10.30.40.0/24 oznaczają przygotowaną strefę i jej rzeczywistą sieć. Resolvery, cele i usługi internetowe dobiera się do potrzeb gości, zamiast ustawiać wszystko na Any. Jeśli sam firewall jest resolverem DNS, jest to usługa lokalna: dostęp DNS należy dopuścić w Administration > Device access wyłącznie ze strefy gości, zamiast kopiować regułę DNS do WAN.

Sprawdzanie logowania i ograniczeń

W sieci gości należy wykonać pełny test pozytywny i negatywny:

1. Klient otrzymuje z sieci gości adres, bramę i DNS.
2. https://login.example.com:8090 jest osiągalny i wyświetla odpowiedni certyfikat.
3. Zwykłe żądanie webowe prowadzi do portalu.
4. Prawidłowe konto gościa może się zalogować.
5. W Current activities > Live users pojawiają się Username i źródłowy adres IP.
6. Dozwolony test Internetu trafia w oczekiwaną regułę użytkownika i Firewall Rule ID.
7. Cel wewnętrzny i niedozwolona usługa pozostają zablokowane.
8. Konto wygasłe, wyłączone lub celowo wpisane nieprawidłowo jest odrzucane.

W sieci gości dual stack procedurę tę należy przetestować osobno dla IPv4 i IPv6, ponieważ SFOS oddzielnie obsługuje uwierzytelnianie webowe dla celów IPv4 i IPv6. W Authentication > Web authentication > Sign out user należy również określić i przetestować moment zakończenia sesji. Never nie pasuje do czasowego dostępu gościnnego.

Pełna procedura dotycząca reguły, Device Access i HTTPS znajduje się w Konfiguracja i testowanie Captive Portal w Sophos Firewall. Przewodnik po portalach rozróżnia User Portal, VPN Portal i Captive Portal.

Wydawanie danych logowania i obsługa kont

W Authentication > Guest users dostępnych jest kilka działań operacyjnych:

• Print: wybranie przewidzianych użytkowników na liście i kontrolowane wydanie ich danych logowania.
• Resend credentials: ponowne wysłanie danych logowania przez skonfigurowaną bramkę SMS.
• Change status: ustawienie konta jako aktywne lub nieaktywne.
• Change password: nadanie nowego hasła po utracie danych lub w razie podejrzenia ich ujawnienia.
• View usage: kontrola wykorzystania Internetu i stanu limitów.
• Reset user accounting: wyzerowanie liczników wykorzystania i ponowne uruchomienie Network Traffic Quota.

Reset user accounting zmienia stan. Wcześniej należy udokumentować konto, aktualne wykorzystanie, czas i powód. Reset nie powinien być pierwszym krokiem diagnostycznym, ponieważ zmienia materiał dowodowy i może ponownie przyznać gościowi limit.

Podczas wycofywania konta najpierw się je wyłącza. W Current activities > Live users wybiera się aktywną sesję i kończy ją przyciskiem Disconnect, a następnie negatywnie testuje ponowne logowanie i ścieżkę danych. Potem sprawdza się niewykorzystane wydruki, dostęp do SMS i ewentualne indywidualne ustawienia nadrzędne. Rekord usuwa się lub pozostawia do usunięcia przez Auto purge on expiry dopiero wtedy, gdy nie ma już żadnych zależności.

Bezpieczne wycofanie bramki SMS: Wcześniej zapisać dokładną nazwę istniejącego profilu, wybór w Guest user registration settings i potrzeby związane z Resend credentials. Udokumentować konfigurację bez sekretów, a potrzebne sekrety przechowywać osobno i bezpiecznie, aby przygotować ręczne odtworzenie profilu; nie czyni to usunięcia odwracalnym. Dopóki potrzebna jest rejestracja lub ponowne wysyłanie danych, najpierw wybrać bramkę zastępczą i na kontrolowanym koncie pilotażowym sprawdzić odbiór SMS-a, pełną rejestrację, logowanie i ponowne wysyłanie. Jeśli samodzielna rejestracja jest kończona, wyłączyć ją przed usunięciem profilu; samo to nie rozwiązuje obowiązków ponownego wysyłania danych. Zachować stary profil, jeśli nie można zweryfikować potrzebnej ścieżki SMS.

Autoryzowane usunięcie przez API wymaga dokładnego Name starego profilu; nie wysyłać usunięcia bez konkretnego celu. Udokumentowana operacja nie dowodzi istnienia określonego przycisku usuwania w interfejsie graficznym ani automatycznej kontroli zależności. Po zmianie ponownie odczytać listę profili i wybór bramki oraz sprawdzić nadal potrzebne ścieżki rejestracji i wysyłania.

Przed pilotażem należy udokumentować ustawienia globalne, bramkę SMS, grupę i regułę. Przy wycofaniu zmian przywraca się poszczególne zmienione wartości; alternatywnie wyłącza się samodzielną rejestrację i regułę pilotażową. Pełne odtworzenie kopii zapasowej nie jest szybkim sposobem cofnięcia zmian: zastępuje bieżącą konfigurację i restartuje firewall; w HA odtworzenie na Primary również powoduje przerwę. Należy je zarezerwować dla udokumentowanej procedury awaryjnej.

Systematyczne zawężanie błędów

Nazwa rekordu nie działa jako Username

W Add single pole Name jest tylko nazwą rekordu użytkownika. Właściwy Username jest generowany na podstawie Guest user settings i widnieje na liście albo na wydruku danych logowania. Należy użyć dokładnie tej wartości razem z wygenerowanym lub zmienionym hasłem.

Konto jest ważne od razu albo jeszcze nie jest ważne

Sprawdzić Validity start i Validity period. Przy Immediately czas biegnie od chwili utworzenia, a przy After first login od pierwszego udanego logowania. Dodatkowo sprawdzić czas i strefę czasową firewalla. Szersza reguła firewall nie naprawi wygasłego konta.

Samodzielna rejestracja nie wysyła SMS

Sprawdzić, czy Enable guest users registration jest aktywne, wybrano właściwy SMS gateway, a numer telefonu, Country code, URL, metoda HTTP, parametry żądania i format odpowiedzi są zgodne z dostawcą. Następnie skontrolować log dostawcy i rzeczywisty odbiór SMS.

Pomyślny Test connection nie dowodzi jeszcze działania całego procesu rejestracji i Captive Portal. Z drugiej strony, według Sophos nieudany test prywatnej wewnętrznej bramki nie dowodzi automatycznie uszkodzenia ścieżki SMS. W obu przypadkach należy przeprowadzić test z rzeczywistym kontem pilotażowym.

Logowanie działa, ale dostęp do Internetu nie

W Current activities > Live users sprawdzić, czy gość jest widoczny z oczekiwanym źródłowym adresem IP. Następnie skontrolować grupę, indywidualne ustawienia nadrzędne użytkownika, ważność, Access Time i limity. W Log Viewer ruch testowy musi trafić w oczekiwaną regułę użytkownika i Firewall Rule ID.

Jeśli użytkownika nie ma w Live users, najpierw sprawdzić ścieżkę logowania w access_server.log z udokumentowanym czasem testu. Jeśli użytkownik jest widoczny, kolejny krok dotyczy reguły, routingu, NAT, DNS lub zasady ochrony. Systematyczne rozwiązywanie błędów uwierzytelniania rozdziela te etapy diagnostyki.

Konta gościa nie można wybrać dla SSL VPN

Jest to oczekiwane zachowanie produktu. Guest users i Guest groups nie są prawidłowymi Policy members dla Remote Access SSL VPN ani IPsec Remote Access. Dla zewnętrznego technika wymagającego VPN należy użyć zwykłego użytkownika z ograniczonymi uprawnieniami oraz odpowiednią konfiguracją MFA i zasadą Remote Access.

Kontrola końcowa

• Gość może osiągnąć tylko przewidziane cele; sieci wewnętrzne i usługi zarządzania pozostają zablokowane.
• Ważność, Access Time, limity i indywidualne ustawienia nadrzędne odpowiadają procesowi wydawania danych.
• Samodzielna rejestracja pozostaje wyłączona do czasu pomyślnego pilotażu SMS i CAPTCHA.
• Live users, ID reguły oraz testy pozytywny i negatywny potwierdzają oczekiwane przypisanie.
• Offboarding kończy aktywne sesje i usuwa niepotrzebne dane logowania oraz wydruki.
• Reset user accounting wykonuje się wyłącznie z udokumentowanego powodu.

Częste pytania