Konfiguracja Surfing i Network Traffic Quota w Sophos Firewall

Surfing quota ogranicza czas dostępu do internetu dostępny dla uwierzytelnionego użytkownika. Network traffic quota ogranicza natomiast ilość przesłanych danych. Obie polityki przypisuje się do użytkownika lub grupy i można je stosować na przykład w salach szkoleniowych, dla gości albo w jasno zdefiniowanych pakietach użytkowania.

W przypadku gości tymczasowych tworzenie konta, ważność, Captive Portal i usuwanie planuje się oddzielnie. Pełny cykl życia opisano w Bezpieczne tworzenie i obsługa kont gości w Sophos Firewall; ten artykuł koncentruje się na limitach.

Skrócona procedura kontrolowanego wdrożenia wygląda następująco:

1. Ustalić, czy ograniczane ma być wykorzystanie czasu, ilość danych, czy oba te zasoby.
2. W Profiles > Surfing quota albo Profiles > Network traffic quota utworzyć nową politykę pilotażową.
3. Przypisać politykę do małej grupy pilotażowej w Authentication > Groups albo do jednego użytkownika testowego w Authentication > Users.
4. Ponownie uwierzytelnić użytkownika i sprawdzić rozpoznaną tożsamość w Current activities > Live users.
5. Do testu użyć reguły zapory opartej na użytkowniku z włączoną opcją Log firewall traffic.
6. Otworzyć użytkownika w Authentication > Users i sprawdzić zużycie w View usage.
7. Przetestować limit, następny cykl i rollback przed dodaniem kolejnych użytkowników.

⚠️ Reset user accounting zeruje zarówno wykorzystany czas surfowania, jak i liczniki ruchu sieciowego. Jest to zmiana stanu, a nie ogólny przycisk diagnostyczny. Przed zresetowaniem należy udokumentować użytkownika, bieżące wartości, godzinę i przyczynę. Współdzielony limit produkcyjny również nie jest zmieniany bezpośrednio; do testów używa się osobnej polityki pilotażowej.

Wybór funkcji odpowiedniej do wymagania

Cztery podobnie nazwane funkcje rozwiązują różne zadania:

• Access Time zezwala użytkownikom na dostęp lub blokuje go w stałych przedziałach czasowych. Nie mierzy zużycia.
• Surfing quota przydziela użytkownikowi zużywalny limit czasu dostępu do internetu.
• Network traffic quota przydziela użytkownikowi zużywalny limit danych.
• Traffic Shaping ogranicza lub priorytetyzuje przepustowość. Niska szybkość transmisji nie jest limitem danych.

Ponadto Web Policy oferuje akcję Quota dla ograniczonego czasowo dostępu do wybranych kategorii WWW. Ta Policy Quota należy do logiki web proxy i nie jest tą samą funkcją co oparty na użytkowniku limit Surfing Quota opisany w tym artykule.

Limit nie tworzy ani reguły zapory, ani tożsamości użytkownika. Zapora musi rozpoznawać użytkownika, ścieżka sieciowa musi być dozwolona, a ruch testowy musi pasować do oczekiwanej reguły. Dopiero wtedy można wiarygodnie zweryfikować działanie limitu.

Dla odrębnego limitu kategorii WWW Policy quota status pokazuje pozostały czas dla każdego użytkownika i Web Policy w okresie 24 godzin. Aby wykonać zatwierdzony reset, wybrać tam odpowiednich użytkowników i Reset. Wcześniej udokumentować użytkownika, politykę i pozostały czas; później sprawdzić wskazania i dozwolone żądanie testowe. Nie mylić tego resetu z Reset user accounting: wyczerpanie limitu kategorii WWW nie uzasadnia zerowania liczników czasu surfowania i danych użytkownika.

Planowanie przykładu i wymagań wstępnych

W całym przykładzie używana jest mała grupa pilotażowa z dwiema oddzielnymi politykami:

• Grupa: Quota_Pilot
• Użytkownik testowy: quota-pilot
• Surfing Quota: Students_InternetTime
• Cycle type: Cyclic (repeat access)
• Cycle hours: 24
• Maximum access time: 02:00
• Network Traffic Quota: Students_DataVolume
• Restriction: Total network traffic
• Cycle type: Cyclic
• Cycle period: Day
• Quota per cycle: 5000 MB
• Maximum quota: Unlimited

Są to celowo niewielkie wartości dokumentacyjne: w każdym 24-godzinnym cyklu dostępne są dwie godziny internetu, a każdego dnia 5000 MB danych. Nazwy, czas, ilość danych, cykl i limit całkowity dostosowuje się do rzeczywistych zasad użytkowania. Małych limitów testowych nie należy kopiować do polityki wyłącznie produkcyjnej bez sprawdzenia ich wpływu.

Przed konfiguracją należy sprawdzić następujące punkty:

1. Użytkownik pilotażowy może zalogować się przy użyciu przewidzianej metody uwierzytelniania.
2. Nazwa użytkownika i adres źródłowy są widoczne w Current activities > Live users.
3. Dla użytkowników AD pole Group w Authentication > Users jest poprawne.
4. Odpowiednia reguła zapory oparta na użytkowniku zezwala na ruch testowy i ma włączone Log firewall traffic.
5. Istniejące przypisania Surfing quota, Network traffic, Access time i Traffic shaping są udokumentowane.
6. Znany jest poprzedni stan oraz alternatywny użytkownik testowy.

Jeśli użytkownik nie jest widoczny jako Live User, najpierw poprawia się uwierzytelnianie. Limit nie może niezawodnie przypisać nieznanego lub obsługiwanego wyłącznie na podstawie adresu IP ruchu do zwykłego kontyngentu użytkownika.

Tworzenie Surfing Quota

Surfing Quota mierzy wykorzystany czas dostępu do internetu. W pomocy SFOS 22 ten sam obiekt jest opisany zarówno w Profiles > Surfing quota, jak i w Web > Surfing quotas. Należy użyć pozycji widocznej w WebAdmin dla zainstalowanej kompilacji.

Można też używać istniejących limitów domyślnych; istniejącą Surfing Quota otwiera się przyciskiem Edit. Należy uwzględnić wpływ na wszystkich przypisanych użytkowników i grupy.

Wybór Cyclic lub Non-cyclic

• Cyclic (repeat access): Limit czasu jest ponownie udostępniany w powtarzających się cyklach. Niewykorzystany czas nie przechodzi do następnego cyklu.
• Non-cyclic (one-time access): Limit czasu jest udostępniany jednorazowo. Po jego wykorzystaniu użytkownik zostaje rozłączony.

Dodatkowo Validity period ogranicza liczbę dni ważności polityki. Maximum access time określa dostępny czas. Po osiągnięciu maksimum użytkownik zostaje rozłączony nawet wtedy, gdy okres ważności limitu jeszcze się nie zakończył.

Jeśli użytkownika obejmuje kilka polityk Surfing Quota, firewall ogranicza dostęp, gdy pierwsza z nich osiągnie swój limit. Dlatego należy wspólnie sprawdzić wszystkie przypisania bezpośrednie i grupowe; druga, wyższa polityka nie znosi już osiągniętego limitu.

Unlimited dla Maximum access time usuwa tylko limit wykorzystanego czasu, a nie oddzielnie ustawioną ważność. Dla jednorazowego, nieograniczonego korzystania przez tydzień można na przykład wybrać Non-cyclic (one-time access), ustawić Validity period na 7 dni i Maximum access time na Unlimited. To inne wymaganie niż dwie godziny na cykl 24-godzinny.

Dla przykładu pilotażowego:

1. Otworzyć Profiles > Surfing quota > Add. Jeśli kompilacja pokazuje funkcję w Web > Surfing quotas, wybrać tam Add.
2. Ustawić Name na Students_InternetTime.
3. W polu Description wpisać na przykład Pilot: 2h per 24h, Owner IT.
4. Ustawić Cycle type na Cyclic (repeat access).
5. Ustawić Cycle hours na 24.
6. Świadomie określić Validity period dla pilota albo wybrać Unlimited tylko wtedy, gdy nie jest potrzebna data wygaśnięcia.
7. Ustawić Maximum access time na 02:00.
8. Zapisać przyciskiem Save.

Zapisana polityka nie ma jeszcze wpływu na ruch. Dopiero przypisanie jej do użytkownika lub grupy łączy limit czasu z tożsamością.

SurfingQuotaPolicy w kontekście XML API

Na potrzeby automatyzacji limit czasu przypisany do użytkownika nosi nazwę SurfingQuotaPolicy. Nie jest to ani Network Traffic Quota, ani akcja Quota w Web Policy. Ochronę dostępu, jawne operacje zapisu oraz rozdzielenie transportu HTTP od wyniku XML opisano w Zabezpieczanie dostępu do XML API. Przed zmianą zachować dokładną nazwę obiektu, wszystkie zapisane wartości oraz przypisania użytkowników i grup; edytować wyłącznie osobną politykę pilotażową.

Dokumentacja referencyjna XML dla SFOS 22.0 i 23.0 wymienia poniższe pola. Są to informacje z dokumentacji, a nie serializacja przetestowana na zaporze:

• Name jest wymagane: String, maksymalnie 60 znaków, bez przecinka; UTF-8 jest dozwolone. Dotyczy to również Delete Surfing Quota Policy. Description jest opcjonalne i ograniczone do 255 znaków. Kolumna wartości domyślnych nie podaje wartości dla tych pól; nie należy na tej podstawie wnioskować o wartości domyślnej stosowanej podczas działania.
• CycleType występuje we wzorcu jako Cyclic/NonCyclic; w żądaniu należałoby wybrać dokładnie jedną potwierdzoną wartość, a nie wyrażenie z ukośnikiem. Tabela parametrów podaje jednak jednocześnie typ String i zakres 1–87840. Nie przenosić tego sprzecznego zakresu do innego pola ani nie interpretować go jako liczbowego kodowania cyklu.
• CycleHours opisano jako opcjonalne pole typu String określające godziny cyklu, bez zakresu liczbowego. CycleMinutes opisano jako wymagane pole typu Integer o maksymalnie czterech cyfrach. W szczególności nie wynika z tego potwierdzony zakres 0–59 dla tego pola. Wzorzec zawiera dodatkowo PerDay z Days/Weekly/Monthly/Yearly, ale tabela parametrów nie wyjaśnia tego pola. Dlatego nie przeliczać ustawienia Cycle hours w interfejsie ani długości cyklu pilota na te pola XML bez uprzedniej weryfikacji.
• Dla ograniczonego okresu ważności Validity opisano jako String z zakresem 0–3660 dni. MaximumHours opisuje ograniczoną całkowitą liczbę godzin surfowania jako String o maksymalnie siedmiu znakach; Minutes to dodatkowa liczba minut jako String w zakresie 0–59. Ważność w dniach i czas możliwy do wykorzystania w godzinach/minutach pozostają odrębnymi ograniczeniami; ważność nie jest przydziałem czasu do wykorzystania.

Poniższy fragment pól z wartościami ograniczonymi, który wyraźnie nie jest kompletnym ani gotowym do wysłania żądaniem, pokazuje to ostatnie rozróżnienie:

<Validity>7</Validity>
<MaximumHours>2</MaximumHours>
<Minutes>0</Minutes>

Przykładowe wartości oznaczają siedem dni ważności i dwie godziny całkowitego czasu surfowania bez dodatkowych minut. Nie przedstawiają pełnej realizacji cyklicznego pilota skonfigurowanego w interfejsie jako „dwie godziny na 24 godziny”. Pola cyklu, przypisanie i jawna operacja zostały celowo pominięte. Liczbę dni i budżet czasu wybiera się na podstawie zatwierdzonych zasad użytkowania; przed przygotowaniem pełnej serializacji należy najpierw porównać API help zainstalowanej kompilacji z obiektem pilotażowym uzyskanym przez odczyt.

Dla wartości nieograniczonych wzorzec pokazuje przy Validity i MaximumHours tekst Unlimited/{Days}; osobne wiersze tabeli dla Validity i Maximum Hours podają natomiast -11 i pusty ciąg znaków ''. Nie potwierdza to, że te zapisy są zamienne, że puste pola zachowują istniejące wartości ani że Maximum Hours ze spacją jest znacznikiem XML. Opis godzin nie pasuje ponadto do symbolu zastępczego {Days} przy MaximumHours. Dopóki sposób przedstawienia cyklu lub kodowanie Unlimited pozostają niewyjaśnione, nie wysyłać żądania zapisu i zlecić wyjaśnienie dla konkretnej kompilacji.

Sprawdzanie odpowiedzi przed kolejną próbą zapisu

W przypadku Add Surfing Quota Policy, Edit Surfing Quota Policy i Delete Surfing Quota Policy operację, kod XML i symbol referencyjny należy rozpatrywać łącznie. Dokumentacja referencyjna dla SFOS 22.0 i 23.0 zawiera te same powiązania:

Message.* to tutaj dosłowne, nierozwiązane klucze z dokumentacji referencyjnej, a nie potwierdzone komunikaty zwracane podczas działania. Sukces HTTP nie oznacza sukcesu operacji XML. Również kod XML 200 nie zastępuje ponownego odczytu zapisanego obiektu docelowego: nazwa, cykl, ważność, godziny i minuty muszą odpowiadać zatwierdzonemu stanowi docelowemu. Dopiero potem zweryfikować przypisanie i działanie za pomocą View usage, ponownego logowania oraz ograniczonego testu zużycia i granicy limitu opisanego w tym artykule; sam zapis nie dowodzi egzekwowania limitu.

W przypadku 500, 502, 504, niejasnej odpowiedzi lub przekroczenia czasu oczekiwania najpierw zachować odpowiedź oczyszczoną z danych wrażliwych i odczytać rzeczywisty stan obiektu, zanim zostanie rozważona jakakolwiek ponowna próba. Przy 502 sprawdzić, czy pod dokładną nazwą jest już zapisany oczekiwany obiekt, czy inny; nie przechodzić automatycznie z Add na Edit. Przy Delete z 504 sprawdzić istniejące odwołania oraz przypisania użytkowników/grup, a nie usuwać zależnych reguł na podstawie przypuszczeń. Przed zatwierdzonym usunięciem w kontrolowany sposób przenieść przypisania, ponownie sprawdzić zależności, a następnie potwierdzić, że brakuje dokładnie tej polityki pilotażowej i że dotychczasowe usługi nadal działają. Kod błędu nie dowodzi ani niezmienionego stanu, ani bezpieczeństwa ponowienia operacji. Reset accounting nie jest sposobem wycofania aktualizacji przez API ani usunięcia.

Tworzenie Network Traffic Quota

Network Traffic Quota mierzy ilość przesłanych danych. Nie ogranicza szybkości. Użytkownik może więc wykorzystać limit szybko lub wolno; jeżeli potrzebne jest ograniczenie przepustowości, dodatkowo planuje się odpowiednią politykę Traffic Shaping.

Ograniczenie całego ruchu lub osobno wysyłania i pobierania

• Total network traffic: Jeden wspólny limit obejmuje łącznie wysyłanie i pobieranie.
• Individual network traffic (Upload & download): Wysyłanie i pobieranie mają osobne limity. Ma to sens tylko wtedy, gdy wymaganie rzeczywiście rozróżnia oba kierunki.

Dostępne są też dwa modele cyklu:

• Cyclic: Limit obowiązuje w każdym wybranym cyklu. Dostępne okresy to Day, Week, Month i Year. Niewykorzystana ilość danych nie przechodzi dalej.
• Non-cyclic: Limit obowiązuje w jednym okresie cyklu.

Quota per cycle określa limit dla każdego cyklu. Opcjonalna Maximum quota dodaje limit całkowity i musi być większa niż limit cyklu. Po wyczerpaniu limitu cyklu lub limitu całkowitego zapora rozłącza użytkownika. Do ponownego połączenia przed zwykłym resetem potrzebne jest Reset user accounting.

Dla przykładu pilotażowego:

1. Otworzyć Profiles > Network traffic quota > Add.
2. Ustawić Name na Students_DataVolume.
3. W polu Description wpisać na przykład Pilot: 5000 MB per day, Owner IT.
4. Ustawić Restriction na Total network traffic.
5. Ustawić Cycle type na Cyclic.
6. Ustawić Cycle period na Day.
7. Ustawić Quota per cycle na 5000 MB.
8. Dla tego cyklicznego przykładu pozostawić Maximum quota jako Unlimited. Jeśli potrzebny jest limit całkowity, musi być większy od limitu cyklu.
9. Zapisać przyciskiem Save.

5000 MB jest wartością wejściową tego przykładu, a nie wartością wymaganą ani wskazówką dotyczącą przeliczania jednostek. W rzeczywistej polityce wartość wynika z zatwierdzonego kontyngentu i jest wprowadzana w jednostce oczekiwanej przez WebAdmin. Polityka rozdzielająca wysyłanie i pobieranie otrzymuje natomiast osobne, uzasadnione wartości dla obu kierunków.

Dostępne są również domyślne polityki Network Traffic; istniejące polityki otwiera się przyciskiem Edit. Aby ustawić skończoną Maximum quota, wyczyścić odpowiednie pole wyboru Unlimited i wprowadzić wartość większą od limitu cyklu. Po zapisaniu ponownie otworzyć i sprawdzić wartości; nie zmieniać współdzielonej polityki produkcyjnej na potrzeby pilotażu.

Przypisywanie limitów do grupy lub użytkownika

Grupa jako zwykły sposób eksploatacji

Dla użytkowników z takim samym limitem polityka grupowa jest łatwiejsza w utrzymaniu niż wiele indywidualnych wartości:

1. Otworzyć Authentication > Groups.
2. Utworzyć grupę Quota_Pilot albo edytować wyraźnie ograniczoną grupę pilotażową.
3. Dla Surfing quota wybrać Students_InternetTime.
4. Dla Network traffic wybrać Students_DataVolume.
5. Nie zmieniać przy okazji innych wartości Access Time, Traffic Shaping, Remote Access ani portalu.
6. Zapisać.
7. Ponownie uwierzytelnić użytkownika pilotażowego i sprawdzić faktycznie używaną grupę.

Bezpieczne zarządzanie grupami użytkowników Sophos Firewall wyjaśnia współdziałanie grup lokalnych i importowanych, grupy głównej oraz wyjątków użytkowników. Właściwy import AD pozostaje opisany w Łączenie Active Directory z Sophos Firewall.

Wspólna weryfikacja nadpisania użytkownika i wyboru w regule

W Authentication > Users można ustawić inne wartości Surfing quota i Network traffic dla pojedynczego użytkownika. Dokumentacja opisuje jednak pierwszeństwo różnie: instrukcja tworzenia użytkowników ogólnie daje pierwszeństwo polityce użytkownika, natomiast przegląd użytkowników uzależnia je od wyboru w regułach i politykach. Wskazuje wartości grupy, gdy wybrano tylko grupę, oraz wartości użytkownika, gdy wybrano użytkownika i jego grupę. Nie należy więc zakładać, że nadpisanie działa bezwarunkowo.

W pilotażu udokumentować rzeczywisty wybór użytkowników i grup w danej regule lub polityce oraz obie wartości limitów. Po nowym logowaniu, za pomocą View usage i ograniczonego przepływu testowego, ustalić, która wartość działa w tej kompilacji i na tej ścieżce. Jeśli wskazania i oczekiwany limit nie są zgodne, zatrzymać wdrożenie; nie rozszerzać reguły produkcyjnej ani nie zmieniać kolejności grup jako szybkiej poprawki. Następnie przywrócić poprzednie przypisania i wybór w regule oraz ponownie sprawdzić działanie.

Jeśli zmiana grupy nie działa dla jednego użytkownika, najpierw sprawdza się jego obiekt użytkownika. Nadpisanie nadaje się do udokumentowanego wyjątku lub pilota, ale z czasem może tworzyć ukryte wyjątki. Aby wrócić do polityki grupowej, w kontrolowany sposób przywraca się poprzedni stan dziedziczenia użytkownika.

W Active Directory liczy się tylko Main Group

Dla użytkowników AD funkcje Surfing Quota i Network Traffic nie używają Other group memberships. Obowiązuje Main Group widoczna w polu Group w Authentication > Users albo jawna polityka użytkownika.

Kolejność w Authentication > Groups > Reorder może zmienić Main Group i jednocześnie wpłynąć na kilka polityk. Nie należy jej zmieniać jako szybkiej poprawki limitu. Po zaplanowanej zmianie grupy ponownie uwierzytelnia się użytkownika i jeszcze raz sprawdza Main Group.

Clientless Users są wykluczeni

Clientless Users nie obsługują Surfing Quota ani Network Traffic. Dla stałego urządzenia bez logowania użytkownika ścieżkę sieciową, harmonogram i ewentualne Traffic Shaping planuje się w wąskiej regule zapory. Limitów użytkownika nie stosuje się jako zamiennika opartego na adresie IP.

Kontrola zużycia i weryfikacja limitu

View usage w WebAdmin

Do wyświetlenia zużycia Sophos wymaga reguły zapory opartej na użytkowniku z włączonym Log firewall traffic. Następnie:

1. Ponownie uwierzytelnić użytkownika pilotażowego.
2. Sprawdzić nazwę użytkownika i adres źródłowy w Current activities > Live users.
3. Otworzyć Authentication > Users i wybrać użytkownika pilotażowego.
4. Otworzyć View usage.
5. Dla Surfing Quota sprawdzić przydzielony czas, wygaśnięcie i wykorzystany czas internetu.
6. Dla Network Traffic sprawdzić Cycle renewal, wysyłanie, pobieranie i przydzielony limit.
7. Wykonać niewielki dozwolony transfer testowy i ponownie sprawdzić zmianę.
8. W Log Viewer powiązać użytkownika, Source, Destination, Service, Firewall Rule ID, Action i znacznik czasu.

Widok miesięczny pokazuje dodatkowo źródłowy adres IP, początek, koniec, czas trwania, wysyłanie i pobieranie. Sama wartość zużycia nie dowodzi jednak, że użyto oczekiwanej ścieżki i właściwej reguły. Dlatego należy łączyć View usage, Log Viewer i rzeczywisty przepływ testowy. Rzetelne testowanie reguły Sophos Firewall opisuje weryfikację reguły.

W View usage należy rozróżniać poszczególne sekcje:

• Policy information: W AD Group pokazuje tylko Main Group. Time allotted to user oznacza przydzielony czas surfowania, Surfing quota expiry date datę jego wygaśnięcia, a Internet usage time zużycie od początku lub ostatniego resetu. Data transfer cycle renewal pokazuje odnowienie cyklicznego limitu danych; dla limitów niecyklicznych wyświetla się N.A..
• Usage information: Upload network traffic i Download network traffic pokazują zużycie całkowite oraz zużycie w bieżącej sesji. Allotted oznacza tutaj maksymalny przydzielony limit danych.
• Current cycle usage information: Dla limitów cyklicznych Cycle upload network traffic i Cycle download network traffic dotyczą wyłącznie bieżącego cyklu dziennego, tygodniowego, miesięcznego lub rocznego. Allotted oznacza tutaj limit cyklu, a nie maksimum całkowite. Aby wyświetlić wcześniejsze sesje, wybrać odpowiedni miesiąc z listy w View usage.

Kontrola użytkownika w User Portal

Widok użytkownika w Internet usage należy odróżniać od administracyjnego View usage:

• Policy information pokazuje grupę użytkownika, przydzielone godziny surfowania, datę wygaśnięcia Surfing Quota, datę odnowienia cyklu danych i już wykorzystany czas internetu. W przypadku konta gościa dodatkowo wyświetlane jest wygaśnięcie konta; wygaśnięcie konta i zużycie limitu odpowiadają na różne pytania.
• Usage information pokazuje przydzielony, wykorzystany i pozostały limit danych dla wysyłania i pobierania.
• Monthly usage pokazuje miesięczny czas surfowania i transfer danych oraz pomaga prześledzić wcześniejsze zużycie, a nie tylko aktualny pozostały limit.

Nie każdy użytkownik widzi wszystkie pola: wyświetlane informacje zależą od typu konta i przypisanych polityk. Brak daty wygaśnięcia konta gościa w przypadku zwykłego konta nie świadczy więc o błędzie limitu. Ten widok użytkownika służy do kontroli zużycia, a nie jako instrukcja zmiany polityki lub zerowania liczników.

W User Portal, w Internet usage, użytkownik może zależnie od typu konta i polityki sprawdzić przydzielony i wykorzystany czas surfowania, odnowienie cyklu, wysyłanie, pobieranie i pozostały limit. Ogranicza to liczbę pytań, ale nie zastępuje administracyjnej weryfikacji przypisania, Main Group, reguły i logów.

Kontrolowany test granicy zużycia

Do testu granicznego używa się osobnej polityki pilotażowej ze świadomie małym, ale wystarczającym limitem. Test nie może dotyczyć grupy produkcyjnej.

1. Udokumentować wartości początkowe w View usage.
2. Uruchomić wyraźnie ograniczony przepływ testowy HTTP lub HTTPS.
3. Podczas testu obserwować zużycie i Log Viewer.
4. Potwierdzić, że osiągnięcie limitu powoduje oczekiwane rozłączenie.
5. Po rozłączeniu ponownie otworzyć View usage oraz udokumentować stan licznika i godzinę.
6. Przetestować następny regularny cykl albo wyraźnie zatwierdzone zresetowanie.
7. Następnie przywrócić politykę pilotażową i wcześniejsze przypisanie.

Bezpieczne używanie Reset user accounting

Reset user accounting zeruje czas surfowania i zużycie ruchu sieciowego użytkownika. Po wyczerpaniu Network Traffic Quota reset jest potrzebny, jeśli użytkownik musi połączyć się ponownie przed następnym regularnym cyklem. Ta procedura nie pozwala przywrócić poprzednich wartości liczników; wartości zapisane wcześniej są dowodem, a nie kopią zapasową możliwą do odtworzenia.

Kontrolowany reset wygląda następująco:

1. Udokumentować użytkownika, zgłoszenie, przyczynę, bieżące wartości limitów i godzinę.
2. Sprawdzić, czy można poczekać na zwykłą zmianę cyklu.
3. Upewnić się, że wybrany jest właściwy użytkownik.
4. Otworzyć użytkownika w Authentication > Users.
5. Otworzyć View usage i zachować wartości początkowe.
6. Uruchomić Reset user accounting tylko z przewidzianą zgodą.
7. Ponownie uwierzytelnić użytkownika i sprawdzić nowe liczniki.
8. Sprawdzić niewielki przepływ testowy, Firewall Rule ID i logi.

Reset nie koryguje niewłaściwej Main Group, braku rozpoznania użytkownika ani blokującej polityki zapory lub WWW. Jeśli te przyczyny nie zostaną najpierw wyjaśnione, problem wróci mimo wyzerowanych liczników.

Systematyczne zawężanie błędów

Limit pozornie nie jest naliczany

Najpierw w Current activities > Live users sprawdzić, czy widoczne są oczekiwana tożsamość i adres źródłowy. Następnie zweryfikować, czy ruch pasuje do reguły zapory opartej na użytkowniku z Log firewall traffic. Gdy brakuje logowania lub przepływ używa innej reguły, View usage może być niepełny.

Potem porównać politykę grupową, nadpisanie użytkownika i, w przypadku AD, Main Group. Nie należy pochopnie zmniejszać limitu tylko po to, aby wymusić widoczny efekt.

Limit grupy działa tylko dla niektórych użytkowników

Nie zakładać, że jawna polityka użytkownika stanowi skuteczne nadpisanie bez sprawdzenia wyboru użytkowników i grup. W Authentication > Users sprawdzić oba pola limitów i Main Group, a także wybór w regule lub polityce faktycznie obsługującej ruch. W AD nie są oceniane Other group memberships. Po zmianie grupy ponownie uwierzytelnić użytkownika.

Użytkownik zostaje nieoczekiwanie rozłączony

W View usage sprawdzić, czy osiągnięto Cycle quota, Maximum quota lub Maximum access time. Następnie osobno skontrolować Access Time, Web Policy, regułę zapory i uwierzytelnianie. Captive Portal może pojawić się również z powodu błędnych poświadczeń lub innych problemów z uwierzytelnianiem; limit nie jest automatycznie przyczyną. Konfiguracja i testowanie Captive Portal w Sophos Firewall opisuje pełną ścieżkę logowania.

Zużycie nie odpowiada oczekiwaniom

Sprawdzić, czy skonfigurowano Total network traffic, czy osobne limity wysyłania i pobierania. Następnie porównać szczegóły miesięczne, źródłowy adres IP, Firewall Rule ID i rzeczywisty transfer testowy. Network Traffic Quota mierzy ilość danych, a nie tylko pobrania widoczne w przeglądarce; ruch w tle uwierzytelnionego użytkownika również może zwiększać zużycie.

Reset pomaga tylko na krótko

Jeśli użytkownik zostaje ponownie rozłączony krótko po resecie, należy sprawdzić wartości polityki, cykl, maksimum, nadpisanie użytkownika i rzeczywiste zużycie. Nie należy wielokrotnie zerować licznika przed zrozumieniem przyczyny.

Rollback i eksploatacja

Kontrolowany rollback przywraca poprzednie przypisania polityk. Wykonany wcześniej reset accounting pozostaje jednak skuteczny:

1. Przywrócić poprzednie przypisania Surfing i Network Traffic dla użytkownika lub grupy pilotażowej.
2. W AD ponownie uwierzytelnić użytkownika i sprawdzić Main Group.
3. Udokumentować View usage i bieżące zużycie.
4. Zresetować accounting w sposób kontrolowany tylko wtedy, gdy uzgodniono to dla testu.
5. Wykonać niewielki przepływ testowy i sprawdzić Firewall Rule ID oraz logi.
6. Usunąć polityki pilotażowe dopiero wtedy, gdy nie istnieją już zależności użytkowników lub grup.
7. Zaktualizować zgłoszenie, ownera, limity i wynik testu.

W eksploatacji każdy współdzielony limit wymaga zrozumiałej nazwy, pola Description, ownera i udokumentowanego uzasadnienia cyklu, kontyngentu oraz limitu całkowitego. Zmiany weryfikuje się z użytkownikiem pilotażowym, pozytywnym testem zużycia i negatywnym testem granicznym.

Lista kontrolna eksploatacji

• Zużycie czasu i danych zostało zaplanowane oddzielnie.
• Surfing Quota i Network Traffic Quota mają zrozumiałe nazwy i ownerów.
• Cycle, Validity, Quota per cycle i Maximum są uzasadnione.
• Polityki są przypisane do właściwej grupy lub użytkownika.
• Sprawdzono nadpisania użytkowników.
• W AD Main Group jest poprawna; nie zakłada się użycia Other group memberships.
• Clientless Users nie są planowani z limitami użytkowników.
• Użytkownik pilotażowy pojawia się jako Live User.
• Reguła zapory oparta na użytkowniku rejestruje ruch testowy.
• View usage, User Portal, Firewall Rule ID i rzeczywiste zużycie są zgodne.
• Reset user accounting jest używane wyłącznie z dokumentacją i zgodą.
• Poprzedni stan i rollback są udokumentowane.

Często zadawane pytania