Konfigurowanie Application Traffic Shaping na Sophos Firewall

Application Traffic Shaping pozwala Sophos Firewall priorytetyzować lub ograniczać poszczególne aplikacje, takie jak Microsoft Teams, VoIP, OneDrive czy usługi kopii zapasowych. Pełny proces oparty na aplikacjach wygląda następująco:

1. W System services > Traffic shaping utworzyć politykę z ustawieniem Policy association > Applications.
2. W Applications > Application filter skonfigurować rozpoznawanie wybranej aplikacji.
3. W Applications > Traffic shaping default przypisać politykę do aplikacji lub kategorii.
4. W Rules and policies > Firewall rules wybrać Application Filter i włączyć Apply application-based traffic shaping policy.

Polityka z ustawieniem Policy association > Rules, wybrana w polu Shape traffic, działa inaczej: kształtuje cały ruch pasujący do reguły firewalla, a nie tylko aplikację wybraną w Application Filter.

⚠️ Traffic Shaping nie tworzy dodatkowej przepustowości. Pozwala jedynie lepiej kontrolować jej podział w miejscu przeciążenia. Jeśli łącze jest stale obciążone, nadal trzeba sprawdzić jego pojemność, kopie zapasowe, synchronizacje w chmurze i inne źródła ruchu.

Traffic Shaping ogranicza szybkość transmisji, a nie całkowitą ilość przesłanych danych. Do zużywalnych limitów czasu lub danych służą natomiast Surfing Quota i Network Traffic Quota.

Wymagania i planowanie przepustowości

Przed konfiguracją należy ustalić:

• Application Control jest wymagane do kształtowania ruchu na podstawie aplikacji. Jest częścią Web Protection i pakietu Standard Protection. Status można sprawdzić w System > Administration > Licensing. Polityka typu Rules nie wymaga natomiast rozpoznawania aplikacji.
• Firewall rozpoznaje daną aplikację, a jej ruch przechodzi przez znaną regułę firewalla.
• Dla tej reguły włączono logowanie.
• Wiadomo, czy wąskim gardłem jest upload, download czy oba kierunki oraz które łącze WAN lub ścieżka SD-WAN są używane.
• Zdefiniowano oczekiwany efekt: Guarantee rezerwuje minimalną przepustowość i zezwala na ruch do limitu, natomiast Limit ustawia tylko górną granicę.

Sophos podaje wartości Traffic Shaping w KBps, podczas gdy testy prędkości zwykle używają kbps lub Mbit/s. 1 KBps odpowiada 8 kbps. Dlatego 100 Mbit/s to około 12'500 KBps, a 20 Mbit/s to około 2'500 KBps.

Podstawą powinny być stabilne wyniki pomiarów, a nie wartość deklarowana przez operatora. Jeśli łącze nominalnie 100/20 Mbit/s osiąga stabilnie tylko 80/15 Mbit/s, należy planować około 10'000/1'875 KBps. Zbyt wysokie wartości przekraczają rzeczywistą przepustowość łącza i dlatego nie pozwalają prawidłowo sterować wąskim gardłem.

Przy łączach asymetrycznych warto włączyć Limit upload/download separately. Teams, VoIP, VPN i kopie zapasowe w chmurze często jako pierwsze odczuwają pełne wykorzystanie uploadu. Ustawienia globalne w System services > Traffic shaping settings dotyczą wyłącznie ruchu wychodzącego przekazywanego przez firewall do strefy WAN. Poszczególne polityki Traffic Shaping mogą natomiast obejmować przekazywany ruch przychodzący i wychodzący. QoS nie obejmuje też ruchu generowanego przez sam firewall, takiego jak aktualizacje wzorców lub synchronizacja licencji.

Rozróżnienie ustawień globalnych i poszczególnych polityk

W System services > Traffic shaping settings wartość Total available WAN bandwidth określa wspólną pojemność QoS wszystkich łączy WAN. Należy wpisać sumę stabilnie dostępnej przepustowości w KBps, a nie tylko umowną prędkość jednego łącza. Show bandwidth usage pokazuje podział tej pojemności między priorytety. Ustawienia globalne dotyczą tylko przekazywanego ruchu wychodzącego do WAN, który nie pasuje do odrębnej polityki Traffic Shaping.

Przy włączonej opcji Optimize for real-time (VoIP) SFOS zawsze nadaje najwyższy priorytet ruchowi czasu rzeczywistego. Gdy opcja jest wyłączona, polityki gwarantujące przepustowość otrzymują najpierw przydzieloną im przepustowość, a ruch czasu rzeczywistego jest obsługiwany z pozostałej puli. Enforce guaranteed bandwidth aktywuje dla ruchu bez własnej polityki wartości Guarantee, Limit i Priority od 1 do 7 z polityki domyślnej. Gdy Enforce guaranteed bandwidth jest wyłączone, ruch ten nie otrzymuje gwarantowanej minimalnej przepustowości, lecz korzysta jedynie z nadal dostępnej przepustowości. W przypadku Priority wartość 1 oznacza najwyższy, a 7 najniższy priorytet.

Nie należy włączać tych opcji jako ogólnej poprawki wydajności. Najpierw trzeba udokumentować rzeczywistą przepustowość, istniejące gwarancje i oczekiwany priorytet. W przeciwnym razie zawyżone gwarancje konkurują o pojemność, która fizycznie nie istnieje.

Konfigurowanie Traffic Shaping opartego na aplikacjach

Poniższy przykład nadaje priorytet ruchowi maksymalnie czterech jednocześnie aktywnych punktów końcowych wideo Teams w małej lokalizacji ze stabilnym łączem około 80/15 Mbit/s. Microsoft podaje w sekcji wymagań dotyczących przepustowości Teams około 2'500 kbps uploadu i 4'000 kbps downloadu na punkt końcowy dla spotkania wideo. Przykładowe wartości rezerwują łączne zapotrzebowanie, ale trzeba je porównać z własnymi pomiarami i rzeczywistą liczbą jednocześnie aktywnych punktów końcowych.

Tworzenie polityki Traffic Shaping

W System services > Traffic shaping należy utworzyć nową politykę, na przykład z następującymi wartościami:

• Name: Teams Guarantee
• Policy association: Applications
• Rule type: Guarantee
• Limit upload/download separately: Enable
• Priority: 1 (najwyższy priorytet)
• Upload Guarantee / Limit: 1'250 / 1'500 KBps
• Download Guarantee / Limit: 2'000 / 5'000 KBps
• Bandwidth usage type: Shared

1'250 KBps odpowiada 10 Mbit/s, a 2'000 KBps odpowiada 16 Mbit/s. Przy ustawieniu Shared wszystkie aplikacje lub kategorie, do których przypisano politykę, korzystają ze wspólnej puli. Individual przydziela natomiast wartość wyłącznie pierwszemu obiektowi, do którego przypisano politykę; polityki Individual nie należy więc planować jako szablonu wielokrotnego użytku dla kilku obiektów. Nie należy rozdzielać wysokich wartości gwarantowanych między zbyt wiele polityk, ponieważ ich suma musi odpowiadać rzeczywiście dostępnej przepustowości. W tym przykładzie gwarancje odpowiadają łącznemu zalecanemu zapotrzebowaniu czterech punktów końcowych wideo Teams. Jeśli dostępna jest dodatkowa przepustowość, mogą z niej korzystać aż do osiągnięcia wyższych limitów. Limity 12/40 Mbit/s celowo pozostawiają przepustowość dla innego ruchu na zmierzonym łączu 80/15 Mbit/s. Są to wartości początkowe, a nie uniwersalne wymagania Teams.

W opisanym tutaj procesie w interfejsie użytkownika polityk Traffic Shaping nie można edytować po ich utworzeniu. To ograniczenie interfejsu użytkownika nie oznacza, że XML API nie dokumentuje operacji aktualizacji. Jeśli później potrzebne są inne wartości, należy najpierw udokumentować wszystkie przypisania, utworzyć politykę zastępczą z nową nazwą i początkowo przełączyć tylko ograniczony zakres. Po weryfikacji należy przenieść pozostałe przypisania; starą politykę usuwa się dopiero wtedy, gdy nie wskazuje na nią żadna referencja. Przy wycofywaniu zmiany należy ponownie przypisać starą politykę lub None.

Polityka QoS: rozróżnienie procesu w interfejsie użytkownika i kontraktu XML API

Dokumentacja referencyjna XML API dla SFOS 22.0 i 23.0 wyraźnie dokumentuje dla QoSPolicy Add QoS policy / Update QoS policy i opisuje dodawanie/edycję. Tym samym operacja API jest udokumentowana, ale nie potwierdzono jeszcze kontraktu aktualizacji nadającego się do wykonania na zainstalowanym buildzie. Poniższe informacje objaśniają dokumentację; nie stanowią przetestowanego szablonu żądania. Instrukcją dostosowywania pozostaje bezpieczny proces zastępowania polityki w interfejsie użytkownika. Dostęp, jawną operację i weryfikację odpowiedzi wyjaśniono w artykule Bezpieczne korzystanie z XML API i interpretowanie odpowiedzi.

Pola przepustowości w przykładzie zależą od PolicyType i ImplementationOn; nie są wszystkie jednocześnie wymagane dla każdej polityki:

• Strict z Total: TotalBandwidth.
• Committed z Total: GuaranteedBandwidth i BurstableBandwidth.
• Strict z Individual: UploadBandwidth i DownloadBandwidth.
• Committed z Individual: GuaranteedUploadBandwidth, BurstableUploadBandwidth, GuaranteedDownloadBandwidth i BurstableDownloadBandwidth.

W przykładzie każda przepustowość Burstable musi być większa od odpowiadającej jej przepustowości gwarantowanej. Warianty Individual wymieniają w komentarzach tylko User, Firewall i Application; WebCategory pojawia się przy Total, a nie przy Individual. Nie jest to potwierdzenie kombinacji Individual-WebCategory ani dowiedziony zakaz jej stosowania podczas działania. Ponadto ImplementationOn z Total/Individual nie jest tym samym polem co BandwidthUsageType z Individual/Shared; identycznie brzmiące tokeny nie są zamiennymi ustawieniami.

Przykład i tabela parametrów nie są w pełni zgodne: przykład podaje 2–2560000 KB, a tabela 2–10240000. Nie wynika z tego uniwersalna górna granica dla danego buildu. Dla BandwidthUsageType przykład pokazuje Individual/Shared, natomiast tabela podaje Shared Bandwidth Usage Type z on/off. PolicyBasedOn używa w przykładzie nazwanych tokenów, podczas gdy Policy Based On w tabeli opisano jako liczbę całkowitą z wartością domyślną 0. Nie wyprowadza się tutaj z tego ani sposobu odwzorowania tokenów, ani bezpiecznej wartości domyślnej w przypadku pominięcia pola.

Również szczegóły harmonogramu mają dwie postacie, których nie powiązano jednoznacznie: przykład pokazuje SchedulebasedPolicyRuleList z Rule, DetailId, PolicyType, warunkowymi polami przepustowości i Schedule; dodatkowo DetailId występuje w obiekcie polityki. Tabela wymienia Implementation On jako tablicę z 6/7, Policy Type jako tablicę z 8/11, listy przepustowości bandwidthlist, grntdbandwidthlist, burstbandwidthlist, upbandwidthlist, downbandwidthlist, grntdupbandwidthlist, grntddownbandwidthlist oraz qosdetailnamelist i ScheduleDetail. Numeryczne wartości wyliczeniowe nie są tutaj odwzorowywane na nazwane tokeny; nie zgaduje się kolejności, tożsamości szczegółów ani zachowania przy aktualizacji lub pominięciu.

Przed zmianą przez API należy wyjaśnić te nierozstrzygnięte limity, nazwy pól i struktury harmonogramu na podstawie API help zainstalowanego buildu. Dopóki kontrakt pozostaje niejasny, nie należy składać żądania zapisu na podstawie przykładu. Należy zabezpieczyć stan sprzed zmiany, przypisania i szczegóły harmonogramu; po zatwierdzonej zmianie oddzielnie odczytać z powrotem obiekt i szczegóły oraz sprawdzić efekt kształtowania ruchu w objętym zmianą przedziale czasowym. Dokumentacja referencyjna wymienia dla operacji Add i Update kody statusu XML 200, 500 i 502. Surowe źródło odwołuje się do nierozwiązanych symboli Message.QOSAddSuccess, Message.QOSAddFail, Message.QOSEditSuccess, Message.QOSEditFail i Message.QOSRecordExist; w wyodrębnionym tekście brakuje komunikatów. Symbole te nie są potwierdzonymi tutaj tekstami komunikatów ani kodami HTTP. Sam status nie potwierdza ani wszystkich szczegółów, ani efektu działania. W przypadku rozbieżności należy zabezpieczyć odpowiedź i stan faktyczny oraz nie ponawiać operacji w ciemno; do zabezpieczonego stanu należy wycofać wyłącznie własną zmianę.

Tworzenie Application Filter

W Applications > Application filter należy utworzyć filtr zawierający wyłącznie wymagany ruch:

1. Nadaj nazwę, na przykład Microsoft Teams.
2. Dodaj regułę Application.
3. Wyszukaj microsoft teams w Smart Filter.
4. Wybierz odpowiednie aplikacje Teams i użyj akcji Allow.
5. Zapisz regułę Application za pomocą Save, a następnie zapisz również Application Filter za pomocą Save.

Nie należy traktować całego Microsoft 365 jako jednej aplikacji. Teams, Exchange, SharePoint i OneDrive generują różny ruch i początkowo powinny być obserwowane osobno. Jeśli celem jest rozpoznawanie i blokowanie zamiast zarządzania przepustowością, pomocna jest instrukcja Konfigurowanie i testowanie Application Control na Sophos Firewall.

Przypisywanie polityki do aplikacji

W Applications > Traffic shaping default należy wyszukać Microsoft Teams lub odpowiednią kategorię aplikacji. Kategorię otwiera się bezpośrednio przez Edit. W przypadku pojedynczej aplikacji należy najpierw rozwinąć kategorię za pomocą Expand, a następnie wybrać Edit przy aplikacji. Potem trzeba wybrać Teams Guarantee i potwierdzić przyciskiem Save.

Polityka dotycząca pojedynczej aplikacji ma pierwszeństwo przed polityką dotyczącą jej kategorii. Gdy jednocześnie pasuje kilka poziomów, ogólny opis Shaping podaje następującą kolejność: aplikacja, kategoria aplikacji, kategoria internetowa, użytkownik, grupa i na końcu reguła zapory sieciowej. W przypadku dodatkowej Rules-Policy nadal należy uwzględnić następującą rozbieżność w dokumentacji.

Przypisanie w Traffic shaping default nie aktywuje jeszcze kształtowania ruchu na podstawie aplikacji; dodatkowo wymagane jest włączenie Apply application-based traffic shaping policy w regule zapory, do której ruch faktycznie został dopasowany. Jeśli jednocześnie ustawiono politykę typu Rules, dokumentacja nie jest jednak jednoznaczna: w przypadku Traffic shaping default opisano nadpisanie przez regułę zapory, natomiast ogólny opis kształtowania ruchu umieszcza aplikacje przed regułami zapory. Nie można na tej podstawie wywnioskować wiarygodnie udokumentowanego wyjątku zależnego od stanu przełącznika. Aby rozpocząć od konfiguracji, którą można jednoznacznie zweryfikować, należy użyć tylko jednego poziomu kształtowania ruchu i sprawdzić jego działanie na podstawie rozpoznanego Application ID, dopasowania do reguły oraz zmierzonej szybkości transmisji danych. Jeśli poziomy są łączone, nie wolno zakładać ich pierwszeństwa bez sprawdzenia.

Aktywowanie reguły firewalla

W Rules and policies > Firewall rules należy otworzyć regułę, przez którą faktycznie przechodzi ruch Teams. W sekcji Other security features:

1. Przy Identify and control applications (App control) wybrać filtr Microsoft Teams.
2. Włączyć Apply application-based traffic shaping policy.
3. Zapisać regułę i wygenerować ruch.

Polityki typu Applications nie wybiera się w polu Shape traffic, lecz pochodzi ona z Traffic shaping default. Ogólny opis kształtowania ruchu podaje kolejność: aplikacja, kategoria aplikacji, kategoria WWW, użytkownik, grupa, a na końcu reguła zapory. Ze względu na odmienną informację o nadpisywaniu dla Traffic shaping default, w przypadku jednoczesnego przypisania polityk jest to informacja z dokumentacji, a nie potwierdzone tutaj pierwszeństwo działania. Kilka poziomów należy łączyć wyłącznie świadomie i sprawdzać z użyciem rzeczywistego ruchu.

Kolejność reguł pozostaje decydująca: jeśli ruch zostanie już dopasowany do bardziej ogólnej reguły znajdującej się wyżej, nie zostanie zastosowany ani filtr, ani kształtowanie ruchu z późniejszej reguły.

Ograniczenie pojedynczej aplikacji lub zagwarantowanie przepustowości kategorii

W przypadku samego górnego limitu procedura pozostaje taka sama, ale Rule type ustawia się na Limit. Przykładem dla już rozpoznanej aplikacji Zoom jest polityka Zoom Limit z ustawieniami Policy association > Applications, Rule type > Limit, Priority > 1, Limit upload/download separately > Disable, Limit > 1000 (KBps) i Bandwidth usage type > Shared. 1000 KBps odpowiada 8 Mbit/s; ta dowolnie wybrana wartość początkowa nie jest zaleceniem dla Zoom i musi być dostosowana do zmierzonej przepustowości łącza oraz oczekiwanej jakości rozmów. Disable oznacza tutaj, że nie są ustawiane oddzielne limity wysyłania i pobierania, a nie że kształtowanie ruchu jest wyłączone. W Applications > Traffic shaping default należy otworzyć Conferencing za pomocą Expand, a przy Zoom meetings przypisać politykę za pomocą Edit. W filtrze aplikacji należy wybrać odpowiednią aplikację za pomocą Smart Filter Zoom. Należy zapisać regułę filtra, filtr i regułę zapory; w regule zapory nadal wymagane są odpowiedni filtr i Apply application-based traffic shaping policy. Przy wystarczającym natężeniu generowanego ruchu należy sprawdzić, czy szybkość transmisji danych utrzymuje się na wybranym limicie i czy rozpoznany Application ID rzeczywiście należy do Zoom.

Aby zapewnić wspólną gwarantowaną przepustowość całej kategorii aplikacji, politykę typu Applications przypisuje się zamiast tego bezpośrednio do kategorii. Przykładowo należy otworzyć Remote Access w Traffic shaping default za pomocą Edit i przypisać politykę Guarantee z ustawieniem Shared. W filtrze aplikacji należy utworzyć regułę z Category > Remote access; następnie zapisać regułę i filtr oraz ustawić filtr i przełącznik kształtowania ruchu w regule zapory, do której ruch został dopasowany. Wszystkie aplikacje objęte tą polityką współdzielą pulę, a nie otrzymują każda pełnej gwarantowanej przepustowości. Gwarantowaną przepustowość i limit dobiera się na podstawie dostępnej przepustowości oraz faktycznie potrzebnych jednoczesnych sesji. Przypisanie kategorii nie zezwala na wcześniej zablokowane aplikacje zdalnego dostępu; istniejące zasady dostępu pozostają wiążące.

Traffic Shaping oparty na regule dla całego ruchu reguły

Jeśli cały ruch precyzyjnie ograniczonej reguły firewalla ma korzystać z tych samych wartości, prostsza jest polityka Rules:

1. W System services > Traffic shaping utworzyć politykę z ustawieniem Policy association > Rules.
2. W Rules and policies > Firewall rules otworzyć odpowiednią regułę.
3. W polu Shape traffic wybrać politykę Rules.
4. Nie włączać Apply application-based traffic shaping policy, jeśli nie są używane dodatkowe polityki Applications.

Filtr aplikacji nie ogranicza automatycznie polityki typu Rules do tej aplikacji. W tym celu sama reguła zapory musi być ściśle ograniczona przez źródło, cel i usługi albo należy zastosować procedurę opartą na aplikacjach. DSCP marking również nie zastępuje kształtowania ruchu: DSCP oznacza pakiety dla kolejnych urządzeń na ścieżce ruchu, natomiast polityka kształtowania ruchu na zaporze gwarantuje lub ogranicza przepustowość.

Polityka typu Rules może w ten sposób kształtować również ruch połączeń VPN, pojedynczych hostów, grup hostów lub usług. Dla ruchu z VPN w odpowiedniej regule stosuje się Source zone > VPN; dla hostów IP lub MAC bądź grup hostów wybiera się żądane obiekty w Source networks and devices. Usługi zawężają zakres portów i protokołów. Kryteria te określają, jaki ruch w ogóle zostanie dopasowany do reguły, zanim zadziała Shape traffic. Nie należy pochopnie ograniczać istniejącej reguły produkcyjnej wyłącznie na potrzeby testu kształtowania ruchu, lecz najpierw sprawdzić, które dozwolone połączenia przestałyby wówczas być objęte tą regułą.

Stosowanie Traffic Shaping do innych obiektów

Policy association już podczas tworzenia określa, gdzie będzie można wybrać politykę: Applications, Web categories, Users lub Rules. W procesie w interfejsie użytkownika nie można później przekształcić polityki w inny typ; nie wyprowadza się z tego możliwości migracji typu przez API. Opcjonalny harmonogram ogranicza czas jej obowiązywania, ale nie zastępuje ani przypisania do obiektu, ani testu działania. Podczas tworzenia polityki Add schedule znajduje się w jej dalszej części: za pomocą Add należy ustawić żądane parametry czasowe, a następnie zapisać politykę za pomocą Save. Zarówno z harmonogramem, jak i bez niego: dopiero przypisanie do aplikacji, kategorii, użytkownika lub reguły sprawia, że polityka zaczyna działać. W przypadku błędu zależnego od czasu należy dodatkowo sprawdzić, czy test odbywa się w skonfigurowanym przedziale czasowym.

Kształtowanie kategorii internetowych

Dla witryny lub kategorii należy utworzyć politykę z Policy association > Web categories i przypisać ją do odpowiedniej kategorii w Web > Categories. Kategoria musi występować w obowiązującej polityce WWW. W regule zapory, do której ruch faktycznie został dopasowany, należy aktywować tę politykę WWW i Apply web category-based traffic shaping. Samo zapisane przypisanie do kategorii nie kształtuje jeszcze żadnego ruchu.

Dla tylko jednej konkretnej witryny własna kategoria jest bardziej przejrzystym rozwiązaniem niż szeroka istniejąca kategoria. Przykładowo należy utworzyć politykę Website Limit z ustawieniami Web categories, Limit, Priority > 1, Limit upload/download separately > Disable, Limit > 1000 (KBps) i Shared. Wartość 8 Mbit/s jest przykładowym górnym limitem, który można dostosować, a nie ogólną wytyczną dla ruchu WWW; wszystkie kategorie przypisane do tej polityki współdzielą pulę. Polityka typu Limit nie gwarantuje minimalnej przepustowości.

1. W Web > Categories > Add utworzyć kategorię, na przykład Example Website, wybrać Classification > Productive, politykę Website Limit i Configure category > Local.
2. W Domain/keyword dodać przykładową domenę www.example.com za pomocą przycisku z plusem i zapisać za pomocą Save. W środowisku produkcyjnym należy zastąpić ją faktycznie wymaganą domeną. Dodatkowe słowo kluczowe, takie jak example, ma sens tylko wtedy, gdy zamierzone jest również szersze dopasowanie na podstawie słowa kluczowego; nie należy bezrefleksyjnie przejmować go z przykładu.
3. W Web > Policies otworzyć obowiązującą politykę WWW i dodać odpowiednią regułę za pomocą Add. W Activities > Show only > Web categories wybrać nową kategorię i zastosować ją za pomocą Apply selected items. Przed Save sprawdzić istniejące zezwolenie na dostęp i kolejność reguł; kształtowanie ruchu nie jest powodem do odblokowywania zablokowanych witryn.
4. W regule zapory, do której ruch faktycznie został dopasowany, w Security features > Web filtering wybrać tę politykę WWW, włączyć Apply web category-based traffic shaping i zapisać regułę.

Następnie, korzystając z dozwolonej witryny z tej kategorii, sprawdzić, czy stosowane są oczekiwana reguła zapory i kategoria WWW oraz czy szybkość transmisji danych przy wystarczającym natężeniu ruchu utrzymuje się na limicie. Witryna nienależąca do kategorii służy jako próba kontrolna. W przypadku nieoczekiwanego dopasowania należy sprawdzić przypisanie domeny lub słowa kluczowego, kolejność reguł polityki WWW oraz inne przypisania kształtowania ruchu.

Przypisywanie kategorii internetowych przez XML API

W przypadku powtarzalnych przypisań kategorii dokumentacja XML opisuje WebFilterCategory z QoSPolicy. Pole wskazuje istniejącą politykę przepustowości; w tym procesie musi ona być odpowiednia dla Web categories. Nie jest to ani polityka WWW, ani akcja Allow/Block. Przed zapisem należy zabezpieczyć zawartość kategorii, dotychczasowe przypisanie kształtowania ruchu i referencje w politykach WWW. Dostęp, jawną operację, kontrakt API dla danego buildu i status XML wyjaśniono w artykule Bezpieczne korzystanie z XML API i interpretowanie odpowiedzi. Poniższe informacje opisują udokumentowane relacje między obiektami i nie stanowią szablonu żądania nadającego się do wykonania ani przetestowanego na konkretnym buildzie firewalla.

W przypadku ConfigureCategory opcja Local używa hierarchii DomainList/Domain i KeywordList/Keyword; opcja External używa URLList/URL dla zewnętrznej listy kategorii. Adres URL zewnętrznej listy nie jest domeną firmową, której ruch ma być ograniczany. Należy sprawdzić pochodzenie, aktualizację i zawartość listy oraz nie łączyć tych dwóch sposobów wprowadzania danych bez weryfikacji. Tabela wymienia dodatkowo 0, nie wyjaśniając jednoznacznie jego znaczenia; nie należy na tej podstawie wyprowadzać alternatywy dla dwóch nazwanych sposobów.

Classification klasyfikuje kategorię, ale nie zezwala na dostęp ani go nie blokuje. Tabela wartości wyliczeniowych wymienia Productive, Unproductive, Acceptable i Objectionable, natomiast opis częściowo używa innych nazw. Nie należy stosować przetłumaczonych nazw klasyfikacji jako wartości API; jeśli kontrakt jest niejasny, najpierw należy sprawdzić API help zainstalowanego buildu i nie wykonywać zapisu. Tabela referencyjna oznacza QoSPolicy jako pole wymagane, o długości maksymalnie 50 znaków i bez przecinka; przykład pokazuje None. Ten przykład nie dokumentuje wartości domyślnej podczas działania ani nie potwierdza, że pominięcie pola zachowuje lub usuwa dotychczasowe przypisanie. W przypadku kształtowania ruchu należy sprawdzić istniejącą politykę z odpowiednim powiązaniem oraz jej faktycznie zapisaną nazwę.

Także po przypisaniu przez API nadal wymagany jest cały opisany powyżej proces w interfejsie użytkownika: kategoria musi być używana w obowiązującej polityce WWW, a ta polityka oraz Apply web category-based traffic shaping muszą być ustawione w regule firewalla, do której ruch faktycznie został dopasowany. Klasyfikacja, zawartość kategorii, dostęp i przepustowość pozostają odrębnymi decyzjami. Korzystając z dozwolonej witryny z kategorii, próby kontrolnej bez dopasowania do kategorii oraz nadal zablokowanego celu, należy sprawdzić, czy zmieniono wyłącznie zamierzone przypisanie przepustowości. Zapisana kategoria nie jest jeszcze dowodem na skuteczne kształtowanie ruchu.

Odpowiedzi dotyczące kategorii różnią się zależnie od operacji. Poniższe wartości to kody statusu XML i niezmienione, nierozwiązane symbole referencyjne, a nie kody HTTP ani potwierdzone tutaj teksty komunikatów:

W przypadku odpowiedzi dotyczących szczegółów należy oddzielnie odczytać z powrotem obiekt kategorii oraz każdy wymagany zbiór domen, słów kluczowych lub list: kod XML 2xx nie oznacza automatycznie, że zapisano wszystkie szczegóły. Wspólna nazwa symbolu dla dwóch kodów powodzenia operacji Add nie wyjaśnia różnicy między nimi. Symbole zawierające «MaxFive» nie potwierdzają uniwersalnego, aktualnego limitu pięciu wpisów; dopuszczalny zakres należy ustalić na podstawie pomocy dla danego buildu. Przed usunięciem należy sprawdzić referencje w politykach WWW, a po nim ustalić, które kategorie faktycznie pozostały; przy zaznaczeniu wielu kategorii nie należy zakładać powodzenia usunięcia wszystkich.

Przed każdą ponowną próbą należy zabezpieczyć odpowiedź, stan faktyczny i Audit Trail. Następnie należy porównać zawartość kategorii, QoSPolicy i referencje z udokumentowanym stanem sprzed zmiany oraz zaplanować wyłącznie nadal niezbędną korektę własnej zmiany. Nie należy w ciemno ponownie tworzyć, aktualizować ani usuwać częściowo zapisanej zmiany. W celu wycofania zmiany należy przywrócić do zabezpieczonego stanu wyłącznie własne przypisanie kategorii/polityki; w przypadku zmienionych wartości przepustowości bezpiecznym procesem w tej instrukcji operacyjnej dla interfejsu użytkownika pozostaje zastosowanie polityki zastępczej. Należy odróżnić od tego udokumentowaną operację aktualizacji QoSPolicy, która podlega opisanym powyżej nierozstrzygniętym kontraktom API.

Użytkownicy, grupy i reguły WAF

Politykę z Policy association > Users przypisuje się w Authentication > Users lub Authentication > Groups. W regule zapory należy włączyć Match known users i wybrać odpowiednich użytkowników lub grupy; faktycznie rozpoznana tożsamość musi odpowiadać temu wyborowi. Natomiast w przypadku reguły WAF politykę typu Rules przypisuje się w Advanced settings > Traffic shaping reguły z Action > Protect with web server protection.

Ogólny opis kształtowania ruchu podaje dla kilku poziomów kolejność: aplikacja, kategoria aplikacji, kategoria WWW, użytkownik, grupa, a na końcu reguła zapory. Przy łączeniu przypisań nadal należy uwzględniać wyjaśnioną powyżej odmienną informację dotyczącą Traffic shaping default. Dlatego należy sprawdzić, która polityka działa, na podstawie rzeczywistego przepływu, rozpoznanego użytkownika lub Application ID oraz reguły, do której ruch faktycznie został dopasowany.

Weryfikacja działania i bezpieczne dostosowanie polityki

Po zmianie nie należy ograniczać się do testu prędkości. Trzeba sprawdzić:

• Czy ruch trafia do oczekiwanej reguły firewalla?
• Czy logi Application Control pokazują oczekiwaną aplikację lub Application ID?
• Czy raporty, takie jak Top Applications, oraz liczniki reguł potwierdzają oczekiwane przypisanie?
• Czy podczas testu rzeczywiście występuje przeciążenie w odpowiednim kierunku?
• Czy przepustowość, opóźnienie, utrata pakietów lub jakość rozmów zmieniają się zgodnie z oczekiwaniem?
• Czy test używa tego samego łącza WAN i tej samej ścieżki SD-WAN co ruch produkcyjny?
• Czy opinie użytkowników usług czasu rzeczywistego potwierdzają wyniki pomiarów technicznych?

Wiarygodne porównanie przed zmianą i po niej wymaga użycia tego samego źródła, celu, kierunku oraz możliwie tego samego przedziału czasu. Instrukcja Testowanie wydajności Sophos Firewall za pomocą iPerf i Speedtest przedstawia odpowiednie metody pomiaru. Przy wielu łączach pomocna jest również instrukcja Sprawdzanie routingu SD-WAN dla Reply Packets i System Traffic na Sophos Firewall.

Aby dostosować ustawienia w interfejsie użytkownika, należy utworzyć nową wersję polityki z ostrożnie zmienionymi wartościami zamiast edytować istniejącą politykę. Najpierw należy przypisać ją do aplikacji, kategorii lub reguły o zawężonym zakresie, obserwować logi i opinie użytkowników, a starą politykę usunąć dopiero po pomyślnej weryfikacji. Należy udokumentować cel, regułę objętą zmianą, wartości, osobę odpowiedzialną i termin przeglądu.

Gdy Traffic Shaping nie działa zgodnie z oczekiwaniem

Aplikacja nie jest rozpoznawana

Najpierw należy sprawdzić, czy właściwy Application Filter jest wybrany w regule firewalla, przez którą rzeczywiście przechodzi ruch. Szerokie lub szyfrowane usługi chmurowe należy zweryfikować w logu Application Control na podstawie rozpoznanego Application ID.

Brak widocznej różnicy po włączeniu kształtowania

Jeśli łącze nie jest obciążone podczas testu, nie ma widocznego wąskiego gardła do sterowania. Inne częste przyczyny to wartości wyższe od rzeczywistej przepustowości, niewłaściwy kierunek, bardziej ogólna reguła firewalla umieszczona wyżej lub inna ścieżka SD-WAN.

W przypadku kształtowania opartego na aplikacjach muszą zgadzać się wszystkie trzy przypisania: polityka typu Applications, przypisanie w Traffic shaping default oraz włączona opcja w regule firewalla. Samo zaznaczenie opcji nie przydziela przepustowości.

Okresowe zatrzymywanie ruchu aplikacji

SFOS 22.0 MR2 Build 546 naprawia NC-178197, błąd powodujący okresowe zatrzymywanie ruchu aplikacji przy użyciu polityki przepustowości opartej na aplikacjach. Jeśli objaw występuje w SFOS 22.0 GA lub MR1, przed przebudową polityk należy sprawdzić wersję firmware i zaktualizować system do MR2 lub nowszej zatwierdzonej wersji.

Problemy z Microsoft 365 lub siecią gościnną

Microsoft 365 należy analizować osobno dla Teams, Exchange, SharePoint i OneDrive, zamiast bez sprawdzenia gwarantować lub ograniczać całą kategorię. W przypadku sieci gościnnej trzeba upewnić się, że ruch faktycznie trafia do zamierzonej reguły oraz że ograniczono nie tylko download, lecz także upload.