Konfiguracja i testowanie Captive Portal w Sophos Firewall

Captive Portal loguje użytkowników, którzy są już połączeni z siecią LAN lub WLAN. Następnie Sophos Firewall może przypisać ich ruch do tożsamości użytkownika i zastosować reguły dla określonych użytkowników lub grup.

Istotne jest współdziałanie wszystkich elementów: portal tworzy przypisanie użytkownika, ale sam nie zezwala na dostęp do internetu. Potrzebna jest do tego również odpowiednia reguła firewalla. Niezależnie od niej muszą działać DNS, routing, NAT i segmentacja sieci.

Cały proces obejmuje sześć kroków:

1. Sprawdzić źródło uwierzytelniania i dozwoloną grupę.
2. Zezwolić na Captive Portal dla strefy klientów w Administration > Device access.
3. Jeśli używany jest zewnętrzny serwer DNS, utworzyć wąską regułę DNS bez powiązania z użytkownikiem.
4. Utworzyć regułę użytkownika z opcjami Match known users oraz Use web authentication for unknown users.
5. W Authentication > Web authentication skonfigurować HTTPS, stronę docelową i wylogowanie.
6. Sprawdzić logowanie przez port 8090, użytkownika w Live users oraz Rule ID w Log Viewer.

Co Captive Portal zapewnia, a czego nie

Captive Portal sprawdza się w przypadku urządzeń BYOD, klientów niezarządzanych oraz sieci bez transparentnego rozpoznawania użytkowników. Użytkownik otwiera stronę internetową, zostaje przekierowany do logowania, a następnie firewall wiąże jego tożsamość ze źródłowym adresem IP. Tożsamość może być używana jako kryterium dopasowania reguły.

Inne portale i metody uwierzytelniania służą do innych zadań:

• Wireless Hotspot jest przeznaczony do dostępu gościnnego za pomocą voucherów, hasła dziennego lub warunków korzystania. Kompletny proces opisano w artykule Konfiguracja Hotspot w Sophos Firewall.
• Guest user to tymczasowe konto lokalne dla Captive Portal. Bezpieczne tworzenie i obsługa kont gości opisuje grupę, ważność, wydawanie danych, samodzielną rejestrację i usuwanie kont.
• VPN Portal jest częścią Remote Access. Captive Portal nie tworzy tunelu VPN i nie powinien być używany jako publiczny portal logowania.
• STAS, AD SSO lub SATC mają rozpoznawać użytkowników bez logowania w przeglądarce. W takich środowiskach Captive Portal może być mechanizmem awaryjnym dla urządzeń, na których transparentne rozpoznawanie nie działa.
• Logowanie Microsoft wymaga osobnej procedury Captive Portal z Microsoft Entra ID SSO.

Przegląd portali Sophos pomaga odróżnić User Portal, VPN Portal, WebAdmin i Captive Portal.

⚠️ Captive Portal nie zastępuje segmentacji. Sieć BYOD lub gościnna pozostaje w osobnej strefie albo VLAN i otrzymuje dostęp tylko do rzeczywiście potrzebnych celów i usług. Logowanie poprawia przypisanie użytkownika, ale nie zabezpiecza automatycznie zbyt szeroko udostępnionej sieci.

Wymagania i przykład

Przed rozpoczęciem konfiguracji należy ustalić następujące elementy:

• Działa lokalne lub zewnętrzne źródło uwierzytelniania. W przypadku Active Directory sprawdzono już połączenie z serwerem oraz grupę; konfigurację opisano w artykule Łączenie Active Directory z Sophos Firewall.
• Znane są strefa klientów, sieć źródłowa i dozwolona grupa użytkowników.
• Klient otrzymuje poprawny adres IP, bramę i działające serwery DNS.
• Dla produkcyjnej nazwy portalu istnieje rekord DNS oraz certyfikat akceptowany przez klientów.
• Istniejąca reguła MASQ/SNAT i routing obejmują później dozwolony ruch internetowy.
• Do testu odbiorczego dostępny jest jeden użytkownik dozwolony i jeden niedozwolony.

W przykładzie użyto następujących wartości:

• Strefa klientów: LAN
• Sieć klientów: 10.30.40.0/24
• Obiekt sieciowy: BYOD_10.30.40.0_24
• Adres IP firewalla w strefie klientów: 10.30.40.1
• Grupa użytkowników: BYOD_Internet
• Nazwa reguły: LAN-BYOD-to-WAN-Captive
• Wewnętrzny serwer DNS: 10.20.0.53
• Nazwa portalu: login.example.com

Tych wartości nie należy kopiować bez weryfikacji. Strefa i sieć muszą odpowiadać rzeczywistemu interfejsowi klientów, adres 10.30.40.1 należy zastąpić adresem IP firewalla na tym interfejsie, a grupa musi pochodzić z używanego źródła uwierzytelniania. Z sieci klientów nazwa portalu musi wskazywać dokładnie ten osiągalny adres firewalla.

Konfiguracja Captive Portal krok po kroku

1. Wybór metody uwierzytelniania

W Authentication > Services, w sekcji Firewall authentication methods, określa się źródła, które firewall sprawdza podczas logowania. Może to być lokalna baza użytkowników albo wcześniej skonfigurowany serwer AD, LDAP lub RADIUS. Tworzenie i testowanie zwykłych lokalnych użytkowników opisuje grupę, hasło, Local, Sign-in Restriction i cykl życia tego modelu. Kolejność ma znaczenie: jeśli skonfigurowano kilka serwerów, SFOS sprawdza je od góry do dołu.

W tym przykładzie grupa BYOD_Internet musi być dostępna na firewallu. W przypadku Active Directory należy ją wcześniej zaimportować. Dopiero potem można wybrać ją w regule użytkownika i jednoznacznie sprawdzić przypisanie podczas testu.

Samo poprawne połączenie z serwerem nie wystarcza. Dlatego później trzeba sprawdzić przy użyciu rzeczywistego logowania w portalu, czy hasło, grupa i reguła użytkownika współdziałają prawidłowo.

2. Zezwolenie na Captive Portal dla strefy źródłowej

W Administration > Device access, w wierszu Captive portal, należy zaznaczyć wyłącznie strefy, z których użytkownicy rzeczywiście mają się logować. W przykładzie jest to LAN. Następnie zapisać ustawienie przyciskiem Apply.

Device Access steruje dostępem do lokalnej usługi firewalla. Zwykła reguła LAN-to-WAN nie może zastąpić tego zezwolenia. Jednocześnie nie należy zapobiegawczo udostępniać Captive Portal dla strefy WAN ani dla niepowiązanych stref wewnętrznych. Artykuł Device Access i Local Service ACL opisuje również szczególny przypadek Web Proxy, w którym lokalne portale mogą być osiągalne mimo bardziej restrykcyjnej tabeli stref.

Jeśli klienty używają samego firewalla jako resolvera DNS, w tej samej macierzy trzeba również zezwolić na DNS dla ich strefy. W przypadku osobnego serwera DNS potrzebna jest natomiast opisana niżej reguła tranzytowa.

3. Zapewnienie DNS przed logowaniem

Przeglądarka może otworzyć login.example.com lub pierwotnie żądaną stronę tylko wtedy, gdy DNS działa jeszcze przed uwierzytelnieniem użytkownika. Jeżeli serwer DNS nie znajduje się na firewallu, w Rules and policies > Firewall rules > Add firewall rule > New firewall rule należy utworzyć osobną regułę:

• Action: Accept
• Source zones: LAN
• Source networks and devices: BYOD_10.30.40.0_24
• Destination zones: strefa serwera DNS
• Destination networks: obiekt hosta dla 10.20.0.53
• Services: DNS
• Log firewall traffic: włączyć na czas testu odbiorczego

Reguła nie otrzymuje powiązania z użytkownikiem, ponieważ klient nie jest jeszcze uwierzytelniony. Przed logowaniem zezwala się tylko na DNS do przewidzianego resolvera, a nie na dowolny ruch. Jeśli środowisko korzysta z kilku serwerów DNS, należy dodać wyłącznie ich konkretne obiekty hostów.

Regułę DNS należy umieścić tak, aby resolver był osiągalny jeszcze przed logowaniem. W przykładzie znajduje się bezpośrednio przed regułą użytkownika i powyżej każdej bardziej ogólnej reguły, która odrzucałaby lub inaczej przetwarzała ruch DNS z tej sieci. Następnie zapisać ją przyciskiem Save.

4. Tworzenie reguły użytkownika

Następnie tworzy się właściwą regułę dostępu. W przykładzie otrzymuje ona następujące wartości:

• Rule name: LAN-BYOD-to-WAN-Captive
• Action: Accept
• Source zones: LAN
• Source networks and devices: BYOD_10.30.40.0_24
• Destination zones: WAN
• Destination networks: wymagane cele internetowe lub Any
• Services: tylko wymagane usługi
• Match known users: włączone
• Use web authentication for unknown users: włączone
• Users or groups: BYOD_Internet
• Log firewall traffic: włączone

Opcja Match known users ustawia tożsamość jako kryterium dopasowania. Use web authentication for unknown users powoduje, że pasujące żądanie WWW od nieuwierzytelnionego użytkownika prowadzi do logowania. Grupa określa, kto po poprawnym uwierzytelnieniu może korzystać z reguły.

W polu Services wartość Any ma sens tylko wtedy, gdy grupa rzeczywiście ma otrzymać pełny dostęp klienta do internetu po zalogowaniu. W przypadku węższego dostępu należy świadomie wybrać HTTP, HTTPS i inne wymagane protokoły. Ruch inny niż WWW nie może sam wyświetlić strony logowania; użytkownik musi najpierw wywołać uwierzytelnienie w przeglądarce albo przy użyciu bezpośredniego adresu URL portalu.

Reguła musi znajdować się powyżej szerokiej reguły allow opartej na adresach IP. W przeciwnym razie ruch zostanie przetworzony wcześniej i nie dotrze do reguły użytkownika. Po sprawdzeniu kolejności należy zapisać regułę przyciskiem Save. Podstawy przetwarzania reguł wyjaśnia artykuł Prawidłowe planowanie reguł firewalla.

5. Konfiguracja HTTPS, przekierowania i wylogowania

W Authentication > Web authentication nie włącza się dostępności portalu, lecz ustawia jego zachowanie.

W konfiguracji produkcyjnej ważne są następujące decyzje:

• Use insecure HTTP instead of HTTPS pozostaje wyłączone. HTTP przesyłałby dane logowania bez szyfrowania i nie działa z Entra ID SSO.
• Show web page after sign-in może przekierować użytkownika do pierwotnie żądanej strony albo do określonej strony wewnętrznej.
• Open web page: In new browser window pozostawia stronę Captive Portal otwartą na potrzeby wylogowania i keepalive. Jeśli zastąpiona zostanie ta sama karta, sposób wylogowania jest dla użytkownika mniej widoczny.
• When captive portal page is closed or redirected wylogowuje użytkownika, gdy firewall przestaje odbierać pakiety keepalive. Może się to zdarzyć również po uśpieniu urządzenia lub zmianie sieci.
• When user is inactive jest właściwsze, jeśli sesja ma kończyć się po określonym czasie bezczynności.
• Never wymaga ręcznego wylogowania i może dłużej utrzymywać nieaktualne powiązania użytkownika z adresem IP.

Nie ma jednego właściwego limitu czasu dla wszystkich środowisk. Na urządzeniach współdzielonych i przy częstej zmianie użytkowników ważniejsze są krótsze sesje; na urządzeniach przypisanych do jednej osoby logowanie może być mniej uciążliwe. Każdy wariant należy sprawdzić podczas uśpienia urządzenia, zmiany WLAN i ręcznego wylogowania. Te lokalne opcje sign-out nie dotyczą Entra ID SSO.

Po dokonaniu wyboru zapisać ustawienia przyciskiem Apply.

6. Sprawdzenie nazwy portalu i certyfikatu

Bezpośredni adres diagnostyczny ma postać:

https://<Firewall-IP>:8090

W przykładzie można najpierw otworzyć https://10.30.40.1:8090. W środowisku produkcyjnym bardziej zrozumiały jest adres https://login.example.com:8090, o ile nazwa wskazuje na firewall i znajduje się w certyfikacie.

Adres IP służy wyłącznie do sprawdzenia osiągalności. Jeśli wybrany certyfikat obejmuje tylko login.example.com, przeglądarka przy otwarciu 10.30.40.1 zgodnie z oczekiwaniem wyświetli ostrzeżenie o niezgodności nazwy. Dlatego współdziałanie DNS i certyfikatu należy zawsze sprawdzać za pomocą nazwy FQDN.

Ustawienia znajdują się w Administration > Admin and user settings > Admin console and end-user interaction. W sekcji Redirect users wybiera się Firewall’s configured hostname lub A different hostname; w przykładzie należy tam wpisać login.example.com. W sekcji Certificate wybiera się certyfikat obejmujący tę nazwę. Wybór certyfikatu dotyczy nie tylko Captive Portal, lecz także innych lokalnych portali firewalla. Dlatego przed zmianą trzeba również sprawdzić WebAdmin, User Portal i VPN Portal.

Certyfikat zaufany publicznie eliminuje ostrzeżenia na urządzeniach niezarządzanych. W przypadku wewnętrznego urzędu certyfikacji lub CA podpisanego przez firewall certyfikat CA musi być zainstalowany jako zaufany na wszystkich klientach. Nazwę certyfikatu, pełny łańcuch i bezpieczne przypisanie opisano w artykule Zarządzanie certyfikatami na Sophos Firewall.

Pełny test logowania i reguły użytkownika

Test odbiorczy rozpoczyna się na kliencie bez aktywnej sesji. W razie potrzeby starą sesję testową można zakończyć w Current activities > Live users.

1. Sprawdzić, czy klient otrzymał adres z sieci 10.30.40.0/24, właściwą bramę i poprawny serwer DNS.
2. Bezpośrednio otworzyć https://10.30.40.1:8090, aby sprawdzić dostępność portalu niezależnie od automatycznego przekierowania w przeglądarce. Jeśli certyfikat zawiera tylko login.example.com, ostrzeżenie o niezgodności nazwy jest oczekiwane. Następnie otworzyć adres FQDN, aby zweryfikować DNS i certyfikat.
3. Bez aktywnej sesji otworzyć zwykłą stronę HTTP i sprawdzić przekierowanie do Captive Portal. Strona HTTPS z zapamiętanym mechanizmem HSTS nie jest wiarygodnym testem.
4. Zalogować się jako dozwolony użytkownik. Jeśli włączono lokalne Sophos MFA, token OTP musi zostać wcześniej zarejestrowany w User Portal. Konfigurację opisano w artykule Włączanie MFA w Sophos Firewall.
5. W Current activities > Live users sprawdzić nazwę użytkownika, adres IP klienta i typ uwierzytelniania.
6. Przetestować dozwoloną stronę oraz cel albo usługę, które celowo nie zostały udostępnione.
7. W Log Viewer odfiltrować adres IP klienta. Wpis musi wskazywać oczekiwanego użytkownika oraz Rule ID reguły LAN-BYOD-to-WAN-Captive.
8. Przy użyciu użytkownika spoza grupy BYOD_Internet sprawdzić, czy logowanie nie zapewnia dostępu przez tę regułę.
9. Wywołać wylogowanie, uśpienie urządzenia lub zmianę sieci i sprawdzić, kiedy użytkownik znika z Live users.

W sieci dual-stack test należy wykonać osobno dla IPv4 i IPv6. SFOS utrzymuje oba przypisania użytkownika oddzielnie, dlatego udany test IPv4 nie potwierdza jeszcze działającego dostępu IPv6.

Ukierunkowana diagnostyka typowych błędów

Portal się nie pojawia

Najpierw należy otworzyć bezpośredni adres URL na porcie 8090. Jeśli nie jest osiągalny, sprawdzić strefę źródłową, opcję Captive portal w Device Access, adres IP klienta, przypisanie stref, DNS oraz FQDN portalu.

Jeśli adres bezpośredni działa, ale automatyczne logowanie się nie pojawia, ruch często jest wcześniej przetwarzany przez bardziej ogólną regułę albo brakuje opcji Use web authentication for unknown users. Ponadto logowanie w przeglądarce może wywołać tylko pasujące żądanie WWW. Programy, które nie korzystają z WWW, nie wyświetlą strony Captive Portal.

Logowanie jest odrzucane

W Authentication > Services należy sprawdzić źródło uwierzytelniania i kolejność. Następnie zweryfikować połączenie z serwerem, hasło, grupę użytkownika, quota, a przy lokalnym MFA także ukończoną rejestrację OTP. Cykliczne dozwolone lub blokowane godziny dostępu sprawdza się oddzielnie za pomocą Access Time dla użytkowników i grup. Procedura Surfing Quota i Network Traffic Quota pokazuje, czy zamiast tego wyczerpano wykorzystany czas internetu lub limit danych.

Jeżeli błąd nie jest jednoznacznie związany z portalem, artykuł Systematyczne rozwiązywanie błędów uwierzytelniania na Sophos Firewall rozdziela osiągalność, wybór usługi, Live Users, Main Group i późniejszą ścieżkę ruchu.

Dla klasycznych prób logowania istotny jest plik access_server.log. Plik oauth_sso_captive.log jest potrzebny wyłącznie w procesie SSO z Microsoft Entra ID. Artykuł Logi usług Sophos Firewall wyjaśnia, jak czytać pliki bez przedwczesnego restartowania usług.

Logowanie udane, ale brak dostępu

Udane logowanie potwierdza wyłącznie uwierzytelnienie. Następnie strefa klientów, sieć źródłowa, grupa, cele, usługi, pozycja reguły, NAT i routing muszą odpowiadać regule użytkownika. Log Viewer pokazuje, która Rule ID rzeczywiście przetwarza ruch. W systematycznej analizie pomaga artykuł Dlaczego reguła Sophos Firewall nie jest dopasowywana.

Użytkownik zostaje niespodziewanie wylogowany

Należy sprawdzić wybraną opcję sign-out, otwarte okno portalu, uśpienie urządzenia, zmianę sieci i bezczynność. Przy opcji When captive portal page is closed or redirected przypisanie kończy się, gdy przestają docierać pakiety keepalive; nie musi to być widoczne dokładnie w chwili zamknięcia okna.

Logowanie pojawia się dopiero po około dwóch minutach

Jeśli w tej samej sieci używany jest STAS, jego faza uczenia może opóźnić przekierowanie. Najpierw należy wtedy sprawdzić stan STAS i nieuwierzytelnionych klientów. Ogólna procedura Captive Portal nie zmienia w tym celu żadnej globalnej wartości CLI; zależności opisano w artykule o STAS.

Kilku użytkowników korzysta z tego samego źródłowego adresu IP

Captive Portal zasadniczo przypisuje tożsamość użytkownika do adresu IP klienta. Dlatego adresy IP dodane w Multi-user hosts na potrzeby Per-Connection AD SSO przez Direct Web Proxy nie mogą korzystać z Captive Portal. Per-Connection AD SSO dla hostów wielu użytkowników opisuje właściwą procedurę i osobną regułę bez Match known users dla pozostałego ruchu.

Częste pytania