Konfigurera Application Traffic Shaping på Sophos Firewall

Med Application Traffic Shaping kan Sophos Firewall prioritera eller begränsa enskilda applikationer som Microsoft Teams, VoIP, OneDrive eller backuptjänster. Det fullständiga applikationsbaserade flödet är:

1. Skapa en policy med Policy association > Applications under System services > Traffic shaping.
2. Konfigurera identifiering av den önskade applikationen under Applications > Application filter.
3. Tilldela policyn till applikationen eller kategorin under Applications > Traffic shaping default.
4. Välj Application Filter under Rules and policies > Firewall rules och aktivera Apply application-based traffic shaping policy.

En policy med Policy association > Rules i fältet Shape traffic är en annan variant. Den formar all trafik som matchar brandväggsregeln, inte bara den applikation som valts i Application Filter.

⚠️ Traffic Shaping skapar ingen extra bandbredd. Det fördelar en flaskhals på ett mer kontrollerat sätt. Om anslutningen är konstant överbelastad måste man fortfarande granska kapacitet, backuper, molnsynkroniseringar och andra trafikkällor.

Traffic Shaping begränsar en datahastighet, inte den totala mängden överförda data. För förbrukningsbara tids- eller datakvoter används i stället Surfing Quota och Network Traffic Quota.

Förutsättningar och planering av bandbredd

Följande bör klargöras före konfigurationen:

• Application Control krävs för applikationsbaserad Shaping. Det ingår i Web Protection och licenspaketet Standard Protection. Statusen visas under System > Administration > Licensing. En ren Rules-policy kräver däremot ingen applikationsidentifiering.
• Brandväggen identifierar den berörda applikationen och trafiken går genom en känd brandväggsregel.
• Loggning är aktiverad för regeln.
• Det är känt om uppladdning, nedladdning eller båda riktningarna är begränsade och vilken WAN-gateway eller SD-WAN-väg som används.
• Den önskade effekten är definierad: Guarantee reserverar en minsta bandbredd och tillåter trafik upp till gränsen, medan Limit endast anger en övre gräns.

Sophos visar Shaping-värden i KBps, medan hastighetstester vanligtvis använder kbps eller Mbit/s. 1 KBps motsvarar 8 kbps. 100 Mbit/s är därför cirka 12'500 KBps och 20 Mbit/s cirka 2'500 KBps.

Stabila mätvärden är avgörande, inte leverantörens angivna hastighet. Om en anslutning som nominellt är 100/20 Mbit/s stabilt endast levererar 80/15 Mbit/s bör man planera med ungefär 10'000/1'875 KBps. För höga värden överstiger anslutningens verkliga kapacitet och kan därför inte styra flaskhalsen korrekt.

För asymmetriska anslutningar bör Limit upload/download separately aktiveras. Teams, VoIP, VPN och molnbackuper påverkas ofta först när uppladdningen är full. De globala värdena under System services > Traffic shaping settings gäller endast utgående trafik som brandväggen vidarebefordrar till WAN-zonen. Enskilda Traffic Shaping-policyer kan däremot tillämpas på vidarebefordrad trafik i båda riktningarna. QoS gäller dessutom inte för systemgenererad trafik från brandväggen, exempelvis Pattern Updates eller licenssynkroniseringar.

Skilj globala standardvärden från enskilda policyer

Under System services > Traffic shaping settings anger Total available WAN bandwidth den gemensamma QoS-kapaciteten för alla WAN-anslutningar. Ange summan av den stabilt tillgängliga bandbredden i KBps, inte bara den avtalade hastigheten för en anslutning. Show bandwidth usage visar hur kapaciteten fördelas mellan prioriteterna. De globala värdena påverkar endast vidarebefordrad utgående WAN-trafik som inte matchar en enskild Traffic Shaping-policy.

Med Optimize for real-time (VoIP) prioriterar SFOS alltid realtidstrafik först. Om alternativet är avstängt får policyer som garanterar bandbredd först sin utlovade bandbredd, och realtidstrafiken tilldelas det som återstår. Enforce guaranteed bandwidth aktiverar värdena Guarantee, Limit och Priority från 1 till 7 från standardpolicyn för trafik utan egen policy. Om Enforce guaranteed bandwidth är avstängt får denna trafik ingen garanterad minimibandbredd, utan endast den kapacitet som fortfarande är tillgänglig. För Priority står 1 för högsta och 7 för lägsta prioritet.

Aktivera inte dessa alternativ som en allmän prestandalösning. Dokumentera först verklig bandbredd, befintliga garantier och önskad prioritet. Annars konkurrerar för höga garantier om kapacitet som inte finns fysiskt.

Konfigurera applikationsbaserad Traffic Shaping

Följande exempel prioriterar trafik från upp till fyra samtidigt aktiva Teams-videoslutpunkter på ett mindre kontor med en stabil anslutning på cirka 80/15 Mbit/s. Microsoft anger i bandbreddskraven för Teams ungefär 2'500 kbps uppladdning och 4'000 kbps nedladdning per slutpunkt som rekommenderat behov för ett videomöte. Exempelvärdena reserverar detta gemensamma behov men måste jämföras med egna mätningar och det faktiska antalet samtidigt aktiva slutpunkter.

Skapa en Traffic-Shaping-policy

Skapa en ny policy under System services > Traffic shaping, till exempel med följande värden:

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

1'250 KBps motsvarar 10 Mbit/s och 2'000 KBps motsvarar 16 Mbit/s. Med Shared delar alla applikationer eller kategorier som tilldelats policyn på samma pott. Individual tilldelar däremot värdet endast till det objekt som policyn först kopplas till. Planera därför inte en Individual-policy som en återanvändbar mall för flera objekt. Höga garantivärden bör inte spridas över för många policyer eftersom summan måste motsvara den verkligt tillgängliga bandbredden. I exemplet motsvarar garantierna det totala rekommenderade behovet för fyra Teams-videoslutpunkter. När bandbredd finns tillgänglig kan de använda den upp till de högre gränserna. Gränserna på 12/40 Mbit/s lämnar medvetet kapacitet för annan trafik på den uppmätta anslutningen på 80/15 Mbit/s. De är startvärden, inte allmänna Teams-krav.

I det UI-arbetsflöde som beskrivs här kan Traffic-Shaping-policyer inte redigeras efter att de har skapats. Denna UI-begränsning innebär inte att XML API saknar en dokumenterad uppdateringsoperation. Om andra värden behövs senare dokumenterar man först alla tilldelningar, skapar en ersättningspolicy med ett nytt namn och flyttar först över tilldelningarna inom en begränsad omfattning. Efter kontrollen följer de övriga tilldelningarna; den gamla policyn tas bort först när inga referenser längre pekar på den. Vid rollback tilldelar man den gamla policyn eller None igen.

QoS-policy: skilj mellan UI-arbetsflödet och XML-API-kontraktet

XML-API-referenserna för SFOS 22.0 och 23.0 dokumenterar uttryckligen Add QoS policy / Update QoS policy för QoSPolicy och beskriver Add/Edit. Därmed finns en dokumenterad API-operation, men inget körbart uppdateringskontrakt har ännu bekräftats för den installerade builden. Följande uppgifter förklarar dokumentationen; de är inte en testad requestmall. Det säkra ersättningsförfarandet i UI är fortfarande vägledningen för justeringar. Åtkomst, explicit operation och svarskontroll förklaras i Använd XML API säkert och tolka svar.

Bandbreddsfälten i exemplet beror på PolicyType och ImplementationOn; alla krävs inte samtidigt för varje policy:

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

I exemplet måste respektive Burstable-bandbredd vara större än den tillhörande garantin. Kommentarerna i Individual-grenarna nämner endast User, Firewall och Application; WebCategory förekommer vid Total, inte vid Individual. Detta bekräftar inte en kombination av Individual och WebCategory och är inte heller ett belagt förbud vid körning. ImplementationOn med Total/Individual är dessutom inte samma fält som BandwidthUsageType med Individual/Shared; likalydande token är inte utbytbara inställningar.

Exemplet och parametertabellen stämmer inte helt överens: Exemplet anger 2–2560000 KB, tabellen 2–10240000. Detta innebär inte någon allmängiltig övre gräns för builden. För BandwidthUsageType visar exemplet Individual/Shared, medan tabellen anger Shared Bandwidth Usage Type med on/off. PolicyBasedOn använder namngivna token i exemplet, medan Policy Based On i tabellen beskrivs som ett heltal med standardvärdet 0. Varken mappningen av dessa token eller ett säkert standardvärde när fältet utelämnas härleds här från detta.

Även schemadetaljerna har två framställningar som inte entydigt har sammanförts: Exemplet visar SchedulebasedPolicyRuleList med Rule, DetailId, PolicyType, de villkorade bandbreddsfälten och Schedule; dessutom finns DetailId på policyobjektet. Tabellen anger Implementation On som en array med 6/7, Policy Type som en array med 8/11, bandbreddslistorna bandwidthlist, grntdbandwidthlist, burstbandwidthlist, upbandwidthlist, downbandwidthlist, grntdupbandwidthlist, grntddownbandwidthlist samt qosdetailnamelist och ScheduleDetail. De numeriska enum-värdena mappas inte till namngivna token här; ordning, detaljidentitet och beteende vid uppdatering eller utelämnande gissas inte.

Före en API-ändring måste API help för den installerade builden klargöra dessa oklara gränser, fältnamn och schemastrukturer. Så länge kontraktet är oklart ska ingen skrivbegäran sättas samman utifrån exemplet. Spara det tidigare tillståndet, tilldelningarna och schemadetaljerna; efter en godkänd ändring ska objekt och detaljer läsas tillbaka separat och trafikformningens effekt kontrolleras inom det berörda tidsfönstret. Referensen anger XML-status 200, 500 och 502 för både Add och Update. Råkällan hänvisar till de oupplösta symbolerna Message.QOSAddSuccess, Message.QOSAddFail, Message.QOSEditSuccess, Message.QOSEditFail och Message.QOSRecordExist; meddelandena saknas i den extraherade texten. Symbolerna är inte meddelandetexter eller HTTP-koder som bekräftas här. En status ensam bekräftar varken alla detaljer eller effekten. Vid avvikelser ska svaret och det aktuella tillståndet sparas, och försöket får inte upprepas blint; återställ endast den egna ändringen till det sparade tillståndet.

Skapa ett Application Filter

Skapa ett filter under Applications > Application filter som endast innehåller den önskade trafiken:

1. Ange ett namn, till exempel Microsoft Teams.
2. Lägg till en Application-regel.
3. Sök efter microsoft teams i Smart Filter.
4. Välj de relevanta Teams-applikationerna och använd åtgärden Allow.
5. Spara Application-regeln med Save och spara därefter även Application Filter med Save.

Microsoft 365 bör inte behandlas som en enda applikation. Teams, Exchange, SharePoint och OneDrive genererar olika trafik och bör först observeras separat. Om målet är identifiering och blockering i stället för bandbreddshantering är Konfigurera och testa Sophos Firewall Application Control rätt vägledning.

Tilldela policyn till applikationen

Sök efter Microsoft Teams eller relevant applikationskategori under Applications > Traffic shaping default. En kategori öppnas direkt med Edit. För en enskild applikation expanderas först kategorin med Expand, därefter väljs Edit för applikationen. Välj sedan Teams Guarantee och bekräfta med Save.

En policy för en enskild applikation har företräde framför en policy för dess kategori. När flera nivåer matchar samtidigt anger den allmänna Shaping-beskrivningen följande ordning: applikation, applikationskategori, webbkategori, användare, grupp och slutligen brandväggsregel. Om det finns en ytterligare Rules-Policy måste följande avvikelse i dokumentationen fortfarande beaktas.

Tilldelningen under Traffic shaping default aktiverar inte i sig applikationsbaserad trafikformning; för detta krävs även Apply application-based traffic shaping policy i den brandväggsregel som faktiskt matchar trafiken. Om en Rules-policy samtidigt är tilldelad är dokumentationen dock inte entydig: För Traffic shaping default beskrivs att brandväggsregeln åsidosätter tilldelningen, medan den allmänna beskrivningen av trafikformning placerar applikationer före brandväggsregler. Utifrån detta går det inte att härleda något tillförlitligt belagt undantag som beror på om reglaget är aktiverat eller inte. För en entydigt verifierbar utgångspunkt används endast en trafikformningsnivå, och effekten kontrolleras med identifierat Application ID, regeltilldelning och uppmätt datahastighet. Om nivåer kombineras får deras inbördes företräde inte förutsättas utan kontroll.

Aktivera brandväggsregeln

Öppna den regel som Teams-trafiken faktiskt går genom under Rules and policies > Firewall rules. I avsnittet Other security features:

1. Välj filtret Microsoft Teams vid Identify and control applications (App control).
2. Aktivera Apply application-based traffic shaping policy.
3. Spara regeln och generera trafik.

Applications-policyn väljs inte i fältet Shape traffic, utan hämtas från Traffic shaping default. Den allmänna beskrivningen av trafikformning anger ordningen applikation, applikationskategori, webbkategori, användare, grupp och sist brandväggsregel. På grund av den avvikande uppgiften om åsidosättning för Traffic shaping default är detta, när policyer tilldelas samtidigt, en uppgift från dokumentationen och inte ett företräde som bekräftas här. Flera nivåer bör endast kombineras medvetet och testas med verklig trafik.

Regelordningen är fortfarande avgörande: Om trafiken redan matchar en mer generell regel högre upp tillämpas varken filtret eller trafikformningen i den senare regeln.

Begränsa en enskild applikation eller garantera bandbredd för en kategori

För en ren övre gräns är arbetsgången densamma, men Rule type sätts till Limit. Ett exempel för en redan identifierad Zoom-applikation är en policy Zoom Limit med Policy association > Applications, Rule type > Limit, Priority > 1, Limit upload/download separately > Disable, Limit > 1000 (KBps) och Bandwidth usage type > Shared. 1000 KBps motsvarar 8 Mbit/s; detta fritt valda startvärde är ingen Zoom-rekommendation och måste anpassas till den uppmätta anslutningen och önskad samtalskvalitet. Disable innebär här att inga separata gränser för uppladdning och nedladdning anges, inte att trafikformningen är avaktiverad. Under Applications > Traffic shaping default öppnas Conferencing med Expand, och policyn tilldelas för Zoom meetings med Edit. I applikationsfiltret väljs den relevanta applikationen via Smart Filter med Zoom. Filterregeln, filtret och brandväggsregeln sparas; i brandväggsregeln krävs fortfarande det relevanta filtret och Apply application-based traffic shaping policy. Vid tillräcklig erbjuden trafik kontrolleras att datahastigheten håller sig vid den valda gränsen och att det identifierade Application ID verkligen tillhör Zoom.

För en gemensam bandbreddsgaranti för en hel applikationskategori tilldelas Applications-policyn i stället direkt till kategorin. Exempelvis öppnas Remote Access under Traffic shaping default med Edit, och en Guarantee-policy med Shared tilldelas. I applikationsfiltret skapas en regel med Category > Remote access; därefter sparas regeln och filtret, och i den brandväggsregel som matchar trafiken anges filtret och reglaget för trafikformning aktiveras. Alla applikationer som omfattas av denna policy delar på poolen; de får inte var för sig hela den garanterade bandbredden. Garanti och gräns väljs utifrån den tillgängliga kapaciteten och de samtidiga sessioner som faktiskt behövs. En kategoritilldelning tillåter inte tidigare blockerade fjärråtkomstapplikationer; befintliga åtkomstregler är fortfarande styrande.

Regelbaserad Traffic Shaping för en hel regel

Om all trafik i en tydligt avgränsad brandväggsregel ska få samma värden är en Rules-policy enklare:

1. Skapa en policy med Policy association > Rules under System services > Traffic shaping.
2. Öppna den berörda regeln under Rules and policies > Firewall rules.
3. Välj Rules-policyn under Shape traffic.
4. Aktivera inte Apply application-based traffic shaping policy om inga ytterligare Applications-policyer används.

Ett applikationsfilter begränsar inte automatiskt en Rules-policy till denna applikation. För detta måste antingen själva brandväggsregeln vara snävt avgränsad via källa, destination och tjänster, eller så används den applikationsbaserade arbetsgången. DSCP marking ersätter inte heller trafikformning: DSCP markerar paket för efterföljande enheter, medan trafikformningspolicyn på brandväggen garanterar eller begränsar bandbredd.

En Rules-policy kan på detta sätt även forma trafik för VPN-anslutningar, enskilda värdar, värdgrupper eller tjänster. För trafik från ett VPN används Source zone > VPN i den relevanta regeln; för IP- eller MAC-värdar respektive värdgrupper väljs de önskade objekten under Source networks and devices. Tjänster avgränsar portar och protokoll. Dessa kriterier avgör vilken trafik som över huvud taget matchar regeln innan Shape traffic får effekt. En befintlig regel i produktionsmiljön bör inte begränsas ogenomtänkt enbart för ett trafikformningstest; först kontrolleras vilka tillåtna anslutningar som därigenom inte längre skulle omfattas av regeln.

Tillämpa Traffic Shaping på andra objekt

Policy association avgör redan när en policy skapas var den kan väljas: Applications, Web categories, Users eller Rules. I UI-arbetsflödet kan en policy därefter inte omvandlas till en annan typ; någon API-typmigrering härleds inte från detta. Ett valfritt schema begränsar dess giltighet i tid, men ersätter varken objekttilldelningen eller funktionstestet. När policyn skapas finns Add schedule längre ned i policyn: Med Add anges de önskade tidsuppgifterna, och därefter sparas policyn med Save. Med eller utan schema: Först tilldelningen till applikation, kategori, användare eller regel gör policyn verksam. Vid ett tidsberoende fel kontrollerar man dessutom om testet sker inom det konfigurerade tidsfönstret.

Forma webbkategorier

För en webbplats eller kategori skapas en policy med Policy association > Web categories, och den tilldelas till den aktuella kategorin under Web > Categories. Kategorien måste ingå i en verksam webbpolicy. I den brandväggsregel som faktiskt matchar trafiken aktiveras denna webbpolicy och Apply web category-based traffic shaping. Enbart en sparad kategoritilldelning formar ännu ingen trafik.

För endast en viss webbplats är en egen kategori lättare att följa än en bred befintlig kategori. Som exempel skapas en policy Website Limit med Web categories, Limit, Priority > 1, Limit upload/download separately > Disable, Limit > 1000 (KBps) och Shared. 8 Mbit/s är en anpassningsbar övre gräns som exempel, inte en allmän riktlinje för webbtrafik; alla kategorier som tilldelats denna policy delar på poolen. En Limit-policy garanterar ingen minimibandbredd.

1. Skapa en kategori, exempelvis Example Website, under Web > Categories > Add, och välj Classification > Productive, policyn Website Limit och Configure category > Local.
2. Lägg till exempeldomänen www.example.com under Domain/keyword med plusknappen och spara med Save. I drift ersätts den med den domän som faktiskt önskas. Ett ytterligare nyckelord som example är endast meningsfullt om även en bredare nyckelordsmatchning avses; det ska inte kopieras blint från ett exempel.
3. Öppna den verksamma webbpolicyn under Web > Policies och lägg till en lämplig regel med Add. Välj den nya kategorin under Activities > Show only > Web categories och lägg till den med Apply selected items. Kontrollera befintliga åtkomsttillstånd och regelordningen före Save; trafikformning är inget skäl att tillåta blockerade webbplatser.
4. Välj denna webbpolicy under Security features > Web filtering i den brandväggsregel som faktiskt matchar trafiken, aktivera Apply web category-based traffic shaping och spara regeln.

Kontrollera därefter med en tillåten webbplats från kategorin att den förväntade brandväggsregeln och webbkategorin tillämpas och att datahastigheten håller sig vid gränsen när trafiken är tillräcklig. En webbplats som inte tillhör kategorin används som kontrollprov. Vid en oväntad matchning kontrolleras domän-/nyckelordstilldelningen, regelordningen i webbpolicyn och andra tilldelningar för trafikformning.

Tilldela webbkategorier via XML API

För återkommande kategoritilldelningar beskriver XML-referensen WebFilterCategory med QoSPolicy. Fältet hänvisar till den befintliga bandbreddspolicyn; för denna arbetsgång måste den vara avsedd för Web categories. Det är varken en webbpolicy eller en Allow-/Block-åtgärd. Spara kategoriinnehåll, befintlig Shaping-tilldelning och webbpolicyreferenser före skrivning. Åtkomst, explicit operation, kontraktet för aktuell build och XML-status förklaras under Använd XML API säkert och tolka svar. Uppgifterna nedan dokumenterar objektrelationer och är inte en körbar requestmall eller en requestmall som har testats på en brandväggsbuild.

För ConfigureCategory använder Local hierarkin DomainList/Domain och KeywordList/Keyword; External använder URLList/URL för en extern kategorilista. URL:en till en extern lista är inte den verksamhetsdomän vars trafik ska begränsas. Kontrollera listans ursprung, uppdatering och innehåll, och blanda inte de två inmatningssätten utan kontroll. Tabellen anger även 0 utan att entydigt förklara dess betydelse; tolka därför inte detta som ett alternativ till de två namngivna sätten.

Classification klassificerar kategorin men tillåter eller blockerar inte åtkomst. Enum-tabellen anger Productive, Unproductive, Acceptable och Objectionable, medan beskrivningen delvis använder andra beteckningar. Använd inte översatta klassificeringsnamn som API-värden; om kontraktet är oklart ska först API help för den installerade builden kontrolleras, och ingen skrivning ska göras. Referenstabellen markerar QoSPolicy som ett obligatoriskt fält med högst 50 tecken och utan kommatecken; exemplet visar None. Detta exempel är inte ett belagt standardvärde vid körning och bekräftar inte att ett utelämnat fält behåller eller tar bort den befintliga tilldelningen. För Shaping-fallet ska den befintliga policyn med rätt koppling och dess faktiskt sparade namn kontrolleras.

Även efter en API-tilldelning krävs hela UI-arbetsgången ovan: Kategorien måste användas i den verksamma webbpolicyn, och denna policy samt Apply web category-based traffic shaping måste vara inställda i den brandväggsregel som faktiskt matchar trafiken. Klassificering, kategoriinnehåll, åtkomst och bandbredd förblir separata beslut. Kontrollera med en tillåten webbplats från kategorin, ett kontrollprov som inte matchar och ett mål som fortfarande är blockerat att endast den avsedda bandbreddstilldelningen har ändrats. En sparad kategori är ännu inget bevis på verksam Shaping.

Kategorisvaren skiljer sig beroende på operation. Följande värden är XML-statuskoder och oförändrade, oupplösta referenssymboler, inte HTTP-koder eller meddelandetexter som bekräftas här:

Vid detaljsvaren ska kategoriobjektet och varje nödvändig uppsättning domäner, nyckelord respektive listor läsas tillbaka separat: En XML-2xx-kod innebär inte automatiskt att alla detaljer har sparats. Det gemensamma symbolnamnet för de två framgångskoderna för Add förklarar inte skillnaden mellan dem. Symbolerna med «MaxFive» belägger ingen allmängiltig aktuell gräns på fem poster; fastställ den tillåtna omfattningen med hjälp av buildens hjälpdokumentation. Kontrollera webbpolicyreferenser före en borttagning och fastställ därefter vilka kategorier som faktiskt finns kvar; utgå inte från att hela borttagningen har lyckats när flera kategorier har valts.

Spara svar, aktuellt tillstånd och Audit Trail före varje nytt försök. Jämför därefter kategoriinnehåll, QoSPolicy och referenser med det dokumenterade tidigare tillståndet och planera endast den egna korrigering som fortfarande behövs. Försök inte blint att skapa, uppdatera eller ta bort en delvis sparad ändring igen. Vid återställning ska endast den egna kategori-/policytilldelningen återställas till det sparade tillståndet; för ändrade bandbreddsvärden är ersättningspolicyn fortfarande det säkra förfarandet i denna UI-runbook. Den dokumenterade uppdateringsoperationen för QoSPolicy ska skiljas från detta och omfattas av de oklara API-kontrakt som förklaras ovan.

Användare, grupper och WAF-regler

En policy med Policy association > Users tilldelas under Authentication > Users eller Authentication > Groups. I brandväggsregeln aktiveras Match known users, och de aktuella användarna respektive grupperna väljs; den identitet som faktiskt identifieras måste stämma överens med detta urval. För en WAF-regel tilldelas däremot en Rules-policy under Advanced settings > Traffic shaping i regeln med Action > Protect with web server protection.

Den allmänna beskrivningen av trafikformning anger vid flera nivåer ordningen applikation, applikationskategori, webbkategori, användare, grupp och sist brandväggsregel. Den avvikande uppgiften för Traffic shaping default som förklaras ovan måste fortfarande beaktas vid kombinerade tilldelningar. Därför kontrolleras vilken policy som får effekt med ett verkligt trafikflöde, den identifierade användaren respektive Application ID och den regel som faktiskt matchar trafiken.

Verifiera effekten och justera policyn säkert

Efter ändringen bör man inte bara köra ett hastighetstest utan även kontrollera:

• Träffar trafiken den förväntade brandväggsregeln?
• Visar Application-Control-loggarna förväntad applikation eller Application ID?
• Bekräftar rapporter som Top Applications och regelräknarna den förväntade tilldelningen?
• Är den berörda riktningen faktiskt överbelastad under testet?
• Förändras bandbredd, latens, paketförlust eller samtalskvalitet som förväntat?
• Går testet över samma WAN-gateway och SD-WAN-väg som produktionstrafiken?
• Bekräftar användare av realtidstjänster även den tekniska mätningen i praktiken?

För en tillförlitlig jämförelse före och efter används samma källa, destination, riktning och om möjligt samma tidsperiod. Guiden Testa Sophos Firewall-prestanda med iPerf och Speedtest visar lämpliga mätmetoder. Vid flera anslutningar hjälper även Kontrollera Sophos Firewall SD-WAN Routing för Reply Packets och System Traffic.

För justeringar i UI skapar man en ny policyversion med försiktigt ändrade värden i stället för att redigera den befintliga policyn. Den tilldelas först till en avgränsad applikation, kategori eller regel; man övervakar loggar och användarfeedback och tar bort den gamla policyn först efter en lyckad kontroll. Syfte, berörd regel, värden, ansvarig och granskningsdatum bör dokumenteras.

När Traffic Shaping inte fungerar som förväntat

Applikationen identifieras inte

Kontrollera först att rätt Application Filter har valts i den brandväggsregel som trafiken faktiskt går genom. Breda eller krypterade molntjänster bör verifieras i Application-Control-loggen med hjälp av identifierat Application ID.

Shaping visar ingen skillnad

Om anslutningen inte är överbelastad under testet finns ingen synlig flaskhals att styra. Andra vanliga orsaker är värden över den verkliga bandbredden, fel riktning, en mer generell brandväggsregel högre upp eller en annan SD-WAN-väg.

För applikationsbaserad Shaping måste dessutom alla tre tilldelningar stämma: en policy av typen Applications, tilldelningen under Traffic shaping default och det aktiverade alternativet i brandväggsregeln. Enbart kryssrutan tilldelar ingen bandbredd.

Applikationstrafiken stoppas periodvis

SFOS 22.0 MR2 Build 546 korrigerar NC-178197, ett fel som gjorde att applikationstrafik kunde stoppas periodvis när en applikationsbaserad bandbreddspolicy användes. Om symptomet uppstår med SFOS 22.0 GA eller MR1 bör man kontrollera firmwareversionen och uppdatera till MR2 eller en nyare godkänd version innan policyn byggs om.

Microsoft 365 eller gästnätet förblir problematiskt

Microsoft 365 bör analyseras separat för Teams, Exchange, SharePoint och OneDrive i stället för att blint garantera eller begränsa hela kategorin. För gästnätet bör man kontrollera att trafiken verkligen träffar den avsedda regeln och att inte bara nedladdning utan även uppladdning är begränsad.