Configurar Application Traffic Shaping na Sophos Firewall

Com Application Traffic Shaping, a Sophos Firewall prioriza ou limita aplicações individuais, como Microsoft Teams, VoIP, OneDrive ou serviços de backup. O fluxo completo baseado em aplicações é o seguinte:

1. Em System services > Traffic shaping, criar uma policy com Policy association > Applications.
2. Em Applications > Application filter, configurar o reconhecimento da aplicação pretendida.
3. Em Applications > Traffic shaping default, atribuir a policy à aplicação ou categoria.
4. Em Rules and policies > Firewall rules, selecionar o Application Filter e ativar Apply application-based traffic shaping policy.

Uma policy com Policy association > Rules selecionada no campo Shape traffic é uma variante diferente: molda todo o tráfego correspondente à regra de firewall, não apenas a aplicação selecionada no Application Filter.

⚠️ O Traffic Shaping não cria largura de banda adicional. Distribui um estrangulamento de forma mais controlada. Se a ligação estiver permanentemente saturada, é ainda necessário verificar a capacidade, os backups, as sincronizações na cloud e outras possíveis causas.

O Traffic Shaping limita uma velocidade de dados, não a quantidade total de dados transferidos. Para créditos de tempo ou dados consumíveis utilizam-se Surfing Quota e Network Traffic Quota.

Planear requisitos e largura de banda

Antes da configuração, deve esclarecer-se o seguinte:

• O Application Control é necessário para o shaping baseado em aplicações. Faz parte da Web Protection e também está incluído no bundle Standard Protection. O estado pode ser consultado em System > Administration > Licensing. Em contrapartida, uma policy baseada apenas em Rules não requer reconhecimento de aplicações.
• A aplicação em causa é reconhecida pela firewall e o tráfego passa por uma regra de firewall conhecida.
• O logging está ativo para essa regra.
• Está claro se o estrangulamento ocorre no upload, no download ou em ambas as direções e que gateway WAN ou caminho SD-WAN é utilizado.
• O efeito pretendido está definido: Guarantee reserva uma largura de banda mínima e permite tráfego até ao limite; Limit define apenas um valor máximo.

A Sophos apresenta os valores de shaping em KBps, enquanto os speed tests utilizam normalmente kbps ou Mbit/s. 1 KBps corresponde a 8 kbps. Assim, 100 Mbit/s correspondem a cerca de 12'500 KBps e 20 Mbit/s a cerca de 2'500 KBps.

Os valores determinantes são medições estáveis, não a indicação do fornecedor. Se uma ligação nominal de 100/20 Mbit/s fornecer de forma fiável apenas 80/15 Mbit/s, o planeamento deve basear-se em cerca de 10'000/1'875 KBps. Valores demasiado elevados ficam acima do estrangulamento real e, por isso, não permitem controlá-lo corretamente.

Em ligações assimétricas, deve ativar-se Limit upload/download separately. Teams, VoIP, VPN e backups na cloud são frequentemente os primeiros a sofrer com um upload saturado. Os valores globais em System services > Traffic shaping settings aplicam-se apenas ao tráfego de saída que a firewall encaminha para a zona WAN. As policies individuais de Traffic Shaping podem, em contrapartida, ser aplicadas ao tráfego encaminhado de entrada e de saída. Além disso, o QoS não se aplica ao tráfego gerado pelo sistema da firewall, como atualizações de padrões ou sincronizações de licenças.

Distinguir as predefinições globais das policies individuais

Em System services > Traffic shaping settings, Total available WAN bandwidth define a capacidade QoS conjunta de todas as ligações WAN. Deve introduzir-se a soma da largura de banda disponível de forma estável, em KBps, e não apenas a velocidade contratual de uma ligação. Show bandwidth usage mostra como essa capacidade está distribuída pelas prioridades. Estes valores globais aplicam-se apenas ao tráfego WAN de saída encaminhado que não corresponde a uma policy Traffic Shaping individual.

Com Optimize for real-time (VoIP), o SFOS dá sempre prioridade ao tráfego em tempo real. Se a opção estiver desativada, as políticas com garantia recebem primeiro a largura de banda que lhes foi garantida e o tráfego em tempo real utiliza a capacidade restante. Enforce guaranteed bandwidth ativa, para o tráfego sem uma política própria, os valores Guarantee, Limit e Priority de 1 a 7 da política predefinida. Se Enforce guaranteed bandwidth estiver desativado, este tráfego não recebe uma largura de banda mínima garantida, mas apenas a capacidade ainda disponível. Em Priority, 1 representa a prioridade mais elevada e 7 a mais baixa.

Estas opções não devem ser ativadas como uma correção geral de desempenho. Primeiro devem documentar-se a largura de banda real, as garantias existentes e a prioridade pretendida. Caso contrário, garantias excessivas competem por uma capacidade que não existe fisicamente.

Configurar Application Traffic Shaping baseado em aplicações

O exemplo seguinte prioriza o tráfego de até quatro endpoints de vídeo do Teams ativos em simultâneo num pequeno local com uma ligação estável de aproximadamente 80/15 Mbit/s. Nos requisitos de largura de banda do Teams, a Microsoft recomenda, por endpoint de uma videoconferência, cerca de 2'500 kbps de upload e 4'000 kbps de download. Os valores do exemplo reservam esta necessidade conjunta, mas devem ser comparados com as próprias medições e com o número real de endpoints ativos em simultâneo.

Criar a policy de Traffic Shaping

Em System services > Traffic shaping, criar uma nova policy, por exemplo com estes valores:

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

1'250 KBps correspondem a 10 Mbit/s e 2'000 KBps a 16 Mbit/s. Com Shared, todas as aplicações ou categorias às quais esta policy é atribuída partilham o mesmo conjunto. Individual, em contrapartida, atribui o valor apenas ao objeto ao qual a policy é associada primeiro; por isso, uma policy Individual não deve ser planeada como modelo reutilizável para vários objetos. Não se devem distribuir valores de garantia elevados por muitas policies, porque a soma tem de ser compatível com a largura de banda realmente disponível. Neste exemplo, as garantias correspondem à necessidade total recomendada de quatro endpoints de vídeo do Teams. Quando existe largura de banda disponível, podem utilizá-la até aos limites superiores. Os limites de 12/40 Mbit/s deixam deliberadamente capacidade para outro tráfego na ligação medida de 80/15 Mbit/s. São valores iniciais, não requisitos universais do Teams.

No procedimento na UI aqui descrito, as políticas de Traffic Shaping não podem ser editadas depois de criadas. Esta limitação da UI não significa que a XML API não documente uma operação de atualização. Se mais tarde forem necessários outros valores, devem documentar-se primeiro todas as atribuições, criar uma política de substituição com um novo nome e aplicá-la inicialmente a um âmbito limitado. Após a verificação, seguem-se as restantes atribuições; a política antiga só deve ser removida quando já não existir qualquer referência à mesma. Para fazer rollback, atribui-se novamente a política antiga ou None.

Política QoS: distinguir o procedimento na UI do contrato da XML API

As referências da XML API para SFOS 22.0 e 23.0 documentam explicitamente Add QoS policy / Update QoS policy para QoSPolicy e descrevem Add/Edit. Assim, está documentada uma operação da API, mas ainda não está confirmado um contrato de atualização executável para o build instalado. As informações seguintes explicam a documentação; não são um modelo de pedido testado. O procedimento seguro de substituição na UI continua a ser a orientação para efetuar ajustes. O acesso, a operação explícita e a verificação das respostas são explicados em Utilizar a XML API em segurança e interpretar as respostas.

No exemplo, os campos de largura de banda dependem de PolicyType e ImplementationOn; não são todos necessários em simultâneo para cada política:

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

No exemplo, a respetiva largura de banda Burstable tem de ser superior à garantia correspondente. Nos comentários dos ramos Individual, são mencionados apenas User, Firewall e Application; WebCategory aparece em Total, não em Individual. Isto não confirma uma combinação Individual-WebCategory, nem constitui uma proibição comprovada em tempo de execução. Além disso, ImplementationOn com Total/Individual não é o mesmo campo que BandwidthUsageType com Individual/Shared; tokens com a mesma designação não são definições intercambiáveis.

O exemplo e a tabela de parâmetros não coincidem em todos os pontos: o exemplo indica 2–2560000 KB, enquanto a tabela indica 2–10240000. Daqui não se deduz um limite superior universal para o build. Para BandwidthUsageType, o exemplo apresenta Individual/Shared, mas a tabela apresenta Shared Bandwidth Usage Type com on/off. No exemplo, PolicyBasedOn utiliza tokens designados pelo nome, enquanto Policy Based On é descrito na tabela como um inteiro com o valor predefinido 0. Não se deduzem daqui nem a correspondência dos tokens nem um valor predefinido seguro em caso de omissão.

Os detalhes de Schedule também têm duas representações que não estão conciliadas de forma inequívoca: o exemplo apresenta SchedulebasedPolicyRuleList com Rule, DetailId, PolicyType, os campos condicionais de largura de banda e Schedule; além disso, DetailId aparece no objeto da política. A tabela indica Implementation On como um array com 6/7, Policy Type como um array com 8/11, as listas de largura de banda bandwidthlist, grntdbandwidthlist, burstbandwidthlist, upbandwidthlist, downbandwidthlist, grntdupbandwidthlist, grntddownbandwidthlist, bem como qosdetailnamelist e ScheduleDetail. Não se estabelece aqui uma correspondência entre as enumerações numéricas e os tokens designados pelo nome; não se fazem suposições sobre a ordem, a identidade dos detalhes ou o comportamento em caso de atualização ou omissão.

Antes de uma alteração através da API, a API help do build instalado tem de esclarecer estes limites, nomes de campos e estruturas de Schedule ainda por resolver. Enquanto o contrato não for claro, não se deve compor um pedido de escrita a partir do exemplo. Guardar o estado anterior, as atribuições e os detalhes de Schedule; após uma alteração aprovada, voltar a ler separadamente o objeto e os detalhes e verificar o efeito do shaping no intervalo de tempo em causa. A referência indica os estados XML 200, 500 e 502 tanto para Add como para Update. A fonte original remete para os símbolos não resolvidos Message.QOSAddSuccess, Message.QOSAddFail, Message.QOSEditSuccess, Message.QOSEditFail e Message.QOSRecordExist; as mensagens não constam do texto extraído. Estes símbolos não são textos de mensagens aqui confirmados nem códigos HTTP. Um estado, por si só, não confirma todos os detalhes nem o efeito. Em caso de divergências, guardar a resposta e o estado atual e não repetir cegamente; reverter apenas a própria alteração para o estado guardado.

Criar o Application Filter

Em Applications > Application filter, criar um filtro que contenha apenas o tráfego pretendido:

1. Atribua um nome, como Microsoft Teams.
2. Adicione uma regra Application.
3. Pesquise microsoft teams no Smart Filter.
4. Selecione as aplicações Teams relevantes e utilize a ação Allow.
5. Guarde a regra Application com Save e, em seguida, guarde também o Application Filter com Save.

O Microsoft 365 não deve ser tratado indiscriminadamente como uma única aplicação. Teams, Exchange, SharePoint e OneDrive geram tráfego diferente e devem ser observados separadamente numa primeira fase. Se o objetivo for o reconhecimento e o bloqueio em vez da largura de banda, consultar Configurar e testar o Sophos Firewall Application Control.

Atribuir a policy à aplicação

Em Applications > Traffic shaping default, procurar Microsoft Teams ou a categoria de aplicações adequada. Uma categoria abre-se diretamente com Edit. Para uma aplicação individual, expande-se primeiro a categoria com Expand e seleciona-se depois Edit na aplicação. Em seguida, escolhe-se Teams Guarantee e confirma-se com Save.

Uma política aplicada a uma aplicação individual tem precedência sobre uma política aplicada à respetiva categoria. Quando vários níveis correspondem simultaneamente, a descrição geral de Shaping indica a seguinte ordem: aplicação, categoria de aplicação, categoria web, utilizador, grupo e, por último, regra de firewall. Se existir uma Rules-Policy adicional, continua a ser necessário ter em conta a seguinte divergência na documentação.

A atribuição em Traffic shaping default ainda não ativa o shaping baseado em aplicações; para tal, é também necessário ativar Apply application-based traffic shaping policy na regra de firewall que efetivamente corresponde ao tráfego. Contudo, quando está simultaneamente definida uma política de Rules, a documentação não é inequívoca: para Traffic shaping default, é descrita uma sobreposição pela regra de firewall, enquanto a descrição geral do shaping coloca as aplicações antes das regras de firewall. Não é possível deduzir daí uma exceção comprovada de forma fiável em função do estado da opção. Para uma abordagem inicial que possa ser verificada de forma inequívoca, utiliza-se apenas um nível de shaping e verifica-se o efeito através da Application ID identificada, da correspondência com a regra e da taxa de transferência de dados medida. Se forem combinados vários níveis, não se deve pressupor a sua precedência sem a verificar.

Ativar a regra de firewall

Em Rules and policies > Firewall rules, abrir a regra através da qual passa efetivamente o tráfego do Teams. Na secção Other security features:

1. Em Identify and control applications (App control), selecionar o filtro Microsoft Teams.
2. Ativar Apply application-based traffic shaping policy.
3. Guardar a regra e gerar tráfego.

A política de Applications não é selecionada no campo Shape traffic, mas provém de Traffic shaping default. A descrição geral do shaping indica a seguinte ordem: aplicação, categoria de aplicações, categoria Web, utilizador, grupo e, por último, regra de firewall. Devido à indicação divergente de sobreposição para Traffic shaping default, quando existem políticas atribuídas simultaneamente, esta ordem constitui uma indicação da documentação e não uma precedência aqui confirmada. A combinação de vários níveis deve ser deliberada e verificada com tráfego real.

A ordem das regras continua a ser decisiva: se o tráfego já corresponder a uma regra mais geral situada acima, não serão aplicados nem o filtro nem o shaping da regra posterior.

Limitar uma aplicação individual ou garantir largura de banda a uma categoria

Para definir apenas um limite máximo, o procedimento mantém-se, mas Rule type é definido como Limit. Um exemplo para uma aplicação Zoom já identificada é uma política Zoom Limit com Policy association > Applications, Rule type > Limit, Priority > 1, Limit upload/download separately > Disable, Limit > 1000 (KBps) e Bandwidth usage type > Shared. 1000 KBps correspondem a 8 Mbit/s; este valor inicial, escolhido livremente, não é uma recomendação do Zoom e deve adequar-se à capacidade medida da ligação e à qualidade de chamada pretendida. Disable significa aqui que não são definidos limites separados para upload e download, e não que o shaping está desativado. Em Applications > Traffic shaping default, abre-se Conferencing com Expand e atribui-se a política a Zoom meetings através de Edit. No Application Filter, seleciona-se a aplicação adequada através do Smart Filter Zoom. Guardam-se a regra do filtro, o filtro e a regra de firewall; na regra de firewall, continuam a ser necessários o filtro adequado e Apply application-based traffic shaping policy. Com um volume suficiente de tráfego oferecido, verifica-se se a taxa de transferência de dados se mantém no limite escolhido e se a Application ID identificada pertence realmente ao Zoom.

Para uma garantia partilhada por toda uma categoria de aplicações, a política de Applications é, em alternativa, atribuída diretamente à categoria. Por exemplo, abre-se Remote Access em Traffic shaping default com Edit e atribui-se uma política Guarantee com Shared. No Application Filter, cria-se uma regra com Category > Remote access; em seguida, guardam-se a regra e o filtro e, na regra de firewall que corresponde ao tráfego, define-se o filtro e ativa-se a opção de shaping. Todas as aplicações abrangidas por esta política partilham a largura de banda disponível no conjunto; não recebem, cada uma, a totalidade da garantia. A garantia e o limite são escolhidos com base na capacidade disponível e nas sessões simultâneas efetivamente necessárias. A atribuição de uma categoria não autoriza aplicações de acesso remoto anteriormente bloqueadas; as regras de acesso existentes continuam a prevalecer.

Traffic Shaping baseado em regra para uma regra completa

Se todo o tráfego de uma regra de firewall claramente delimitada tiver de receber os mesmos valores, uma policy Rules é mais simples:

1. Em System services > Traffic shaping, criar uma policy com Policy association > Rules.
2. Em Rules and policies > Firewall rules, abrir a regra em causa.
3. Em Shape traffic, selecionar a policy Rules.
4. Não ativar Apply application-based traffic shaping policy, exceto se forem utilizadas policies Applications adicionais.

Um Application Filter não restringe automaticamente uma política de Rules a essa aplicação. Para tal, a própria regra de firewall tem de estar estritamente delimitada através da origem, do destino e dos serviços, ou deve utilizar-se o procedimento baseado em aplicações. DSCP marking também não substitui o shaping: o DSCP marca pacotes para dispositivos a jusante, enquanto a política de shaping na firewall garante ou limita a largura de banda.

Uma política de Rules também pode, desta forma, aplicar shaping a ligações VPN, hosts individuais, grupos de hosts ou serviços. Para tráfego proveniente de uma VPN, utiliza-se Source zone > VPN na regra adequada; para hosts IP ou MAC, ou grupos de hosts, selecionam-se os objetos pretendidos em Source networks and devices. Os serviços delimitam as portas e os protocolos. Estes critérios determinam que tráfego corresponde à regra, antes de Shape traffic atuar. Não se deve restringir irrefletidamente uma regra existente em produção apenas para um teste de shaping; deve verificar-se previamente que ligações permitidas deixariam, por esse motivo, de ser abrangidas pela regra.

Aplicar Traffic Shaping a outros objetos

Policy association determina, logo na criação, onde uma política pode ser selecionada: Applications, Web categories, Users ou Rules. No procedimento na UI, não é possível converter posteriormente uma política para outro tipo; daqui não se deduz uma migração de tipo através da API. Um Schedule opcional limita a sua validade temporal, mas não substitui a atribuição ao objeto nem o teste funcional. Durante a criação, encontra-se Add schedule mais abaixo na política: com Add, definem-se os períodos pretendidos e, em seguida, guarda-se a política com Save. Com ou sem Schedule, a política só produz efeito após ser atribuída a uma aplicação, categoria, utilizador ou regra. Em caso de falha dependente do horário, verifica-se também se o teste está a decorrer dentro do intervalo de tempo configurado.

Aplicar shaping a categorias web

Para um site ou uma categoria, cria-se uma política com Policy association > Web categories e atribui-se à categoria em questão em Web > Categories. A categoria tem de constar de uma Web Policy efetiva. Na regra de firewall que efetivamente corresponde ao tráfego, ativam-se essa Web Policy e Apply web category-based traffic shaping. Uma atribuição de categoria guardada, por si só, ainda não aplica shaping a qualquer tráfego.

Para apenas um site específico, uma categoria própria é mais fácil de compreender e verificar do que uma categoria existente abrangente. Como exemplo, cria-se uma política Website Limit com Web categories, Limit, Priority > 1, Limit upload/download separately > Disable, Limit > 1000 (KBps) e Shared. Os 8 Mbit/s são um limite máximo de exemplo ajustável, não uma definição geral para a Web; todas as categorias atribuídas a esta política partilham a largura de banda disponível no conjunto. Uma política de Limit não garante uma largura de banda mínima.

1. Em Web > Categories > Add, criar uma categoria como Example Website e selecionar Classification > Productive, a política Website Limit e Configure category > Local.
2. Em Domain/keyword, adicionar o domínio de exemplo www.example.com com o botão de adição e guardar com Save. Em produção, este é substituído pelo domínio efetivamente pretendido. Uma palavra-chave adicional como example só faz sentido se também se pretender uma correspondência mais abrangente por palavra-chave; não deve ser copiada cegamente de um exemplo.
3. Em Web > Policies, abrir a Web Policy efetiva e adicionar uma regra adequada com Add. Em Activities > Show only > Web categories, selecionar a nova categoria e aplicar com Apply selected items. Antes de Save, verificar a permissão de acesso existente e a ordem das regras; o shaping não é motivo para permitir o acesso a sites bloqueados.
4. Na regra de firewall que efetivamente corresponde ao tráfego, selecionar esta Web Policy em Security features > Web filtering, ativar Apply web category-based traffic shaping e guardar a regra.

Em seguida, utilizar um site permitido da categoria para verificar se são aplicadas a regra de firewall e a categoria Web esperadas e se a taxa de transferência de dados se mantém no limite quando existe tráfego suficiente. Um site que não pertença à categoria serve de teste de controlo. Se ocorrer uma correspondência inesperada, verificam-se a associação de domínio/palavra-chave, a ordem das regras da Web Policy e outras atribuições de shaping.

Atribuir categorias web através da XML API

Para atribuições recorrentes de categorias, a referência XML descreve WebFilterCategory com QoSPolicy. O campo remete para a política de largura de banda existente; para este procedimento, a política tem de corresponder a Web categories. Não se trata de uma Web Policy nem de uma ação Allow/Block. Antes de escrever, guardar o conteúdo da categoria, a atribuição de shaping anterior e as referências às Web Policies. O acesso, a operação explícita, o contrato do build e o estado XML são explicados em Utilizar a XML API em segurança e interpretar as respostas. As informações seguintes são relações entre objetos descritas na documentação, não um modelo de pedido executável ou testado num build de firewall.

Em ConfigureCategory, Local utiliza a hierarquia DomainList/Domain e KeywordList/Keyword; External utiliza URLList/URL para uma lista externa de categorias. O URL de uma lista externa não é o domínio da empresa cujo tráfego se pretende limitar. Verificar a origem, a atualização e o conteúdo da lista e não combinar as duas vias de entrada sem as verificar. A tabela apresenta também 0, sem explicar inequivocamente o seu significado; não deduzir daí uma alternativa às duas vias identificadas pelo nome.

Classification classifica a categoria, mas não permite nem bloqueia o acesso. A tabela de enumeração indica Productive, Unproductive, Acceptable e Objectionable, enquanto a descrição utiliza, em parte, outras designações. Não utilizar nomes de classificação traduzidos como valores da API; se o contrato não for claro, consultar primeiro API help do build instalado e não efetuar qualquer escrita. A tabela de referência assinala QoSPolicy como campo obrigatório com um máximo de 50 caracteres e sem vírgulas; o exemplo apresenta None. Este exemplo não constitui uma predefinição de execução comprovada nem confirma que a omissão do campo mantém ou remove a atribuição anterior. Para o caso de shaping, verificar a política existente com a associação adequada e o nome efetivamente guardado.

Mesmo após uma atribuição através da API, o procedimento na UI descrito acima continua a ser integralmente necessário: a categoria tem de ser utilizada na Web Policy efetiva, e essa política e Apply web category-based traffic shaping têm de estar definidas na regra de firewall que efetivamente corresponde ao tráfego. A classificação, o conteúdo da categoria, o acesso e a largura de banda continuam a ser decisões separadas. Utilizar um site permitido da categoria, um teste de controlo sem correspondência e um destino que continue bloqueado para verificar que apenas foi alterada a atribuição de largura de banda pretendida. Uma categoria guardada ainda não comprova que o shaping esteja efetivamente a ser aplicado.

As respostas relativas às categorias diferem consoante a operação. Os valores seguintes são códigos de estado XML e símbolos de referência não resolvidos, mantidos sem alterações, não códigos HTTP nem textos de mensagens aqui confirmados:

Nas respostas relativas aos detalhes, voltar a ler separadamente o objeto da categoria e cada conjunto necessário de domínios, palavras-chave ou listas: um código XML 2xx não significa automaticamente que todos os detalhes tenham sido guardados. O nome de símbolo comum aos dois códigos de sucesso de Add não explica a diferença entre eles. Os símbolos com «MaxFive» não comprovam um limite atual universal de cinco entradas; confirmar o âmbito permitido na ajuda do build. Antes de eliminar, verificar as referências às Web Policies e, depois, determinar quais as categorias que efetivamente permanecem; numa seleção múltipla, não presumir que todas as eliminações foram bem-sucedidas.

Antes de cada nova tentativa, guardar a resposta, o estado atual e o Audit Trail. Em seguida, comparar o conteúdo da categoria, QoSPolicy e as referências com o estado anterior documentado e planear apenas a correção própria ainda necessária. Não voltar a criar, atualizar ou eliminar cegamente uma alteração parcialmente guardada. Para reverter, repor apenas a própria atribuição de categoria/política no estado guardado; para valores de largura de banda alterados, a política de substituição continua a ser o procedimento seguro neste runbook da UI. A operação de atualização de QoSPolicy documentada deve ser distinguida deste procedimento e está sujeita aos contratos da API ainda por esclarecer, explicados acima.

Utilizadores, grupos e regras WAF

Uma política com Policy association > Users é atribuída em Authentication > Users ou Authentication > Groups. Na regra de firewall, ativa-se Match known users e selecionam-se os utilizadores ou grupos em questão; a identidade efetivamente identificada tem de corresponder a esta seleção. Para uma regra WAF, em contrapartida, atribui-se uma política de Rules em Advanced settings > Traffic shaping à regra com Action > Protect with web server protection.

Quando existem vários níveis, a descrição geral do shaping indica a seguinte ordem: aplicação, categoria de aplicações, categoria Web, utilizador, grupo e, por último, regra de firewall. A indicação divergente para Traffic shaping default, explicada acima, continua a ter de ser tida em conta quando se combinam atribuições. Por isso, verifica-se qual a política que produz efeito através de um fluxo real, do utilizador identificado ou da Application ID e da regra que efetivamente corresponde ao tráfego.

Verificar o efeito e ajustar a policy em segurança

Depois da alteração, não basta executar um speed test. Deve verificar-se também:

• O tráfego corresponde à regra de firewall esperada?
• Os logs do Application Control mostram a aplicação ou o Application ID esperado?
• Relatórios como Top Applications e os contadores das regras confirmam a atribuição esperada?
• A direção em causa está efetivamente saturada durante o teste?
• A largura de banda, a latência, a perda de pacotes ou a qualidade das chamadas mudam como esperado?
• O teste utiliza o mesmo gateway WAN e o mesmo caminho SD-WAN que o tráfego de produção?
• Os utilizadores dos serviços em tempo real também confirmam na prática a medição técnica?

Para uma comparação fiável antes e depois da alteração, deve utilizar-se a mesma origem, o mesmo destino, a mesma direção e, se possível, o mesmo período. O guia Testar o desempenho da Sophos Firewall com iPerf e Speedtest apresenta métodos de medição adequados. Com várias ligações, consultar também Verificar o routing SD-WAN da Sophos Firewall para Reply Packets e System Traffic.

Para efetuar ajustes na UI, cria-se uma nova versão da política com valores alterados de forma prudente, em vez de editar a política existente. Atribui-se primeiro esta nova versão a uma aplicação, categoria ou regra de âmbito limitado, observam-se os logs e o feedback dos utilizadores e remove-se a política antiga apenas após uma verificação bem-sucedida. Devem documentar-se a finalidade, a regra em causa, os valores, o responsável e a data de revisão.

Quando o Traffic Shaping não funciona como esperado

A aplicação não é reconhecida

Verificar primeiro se o Application Filter correto está selecionado na regra de firewall que é efetivamente utilizada. Em serviços cloud abrangentes ou encriptados, confirmar o Application ID reconhecido no log do Application Control.

O shaping não mostra diferenças

Se a ligação não estiver saturada durante o teste, não existe um estrangulamento visível para controlar. Outras causas frequentes são valores acima da largura de banda real, a direção errada, uma regra de firewall mais geral colocada acima ou um caminho SD-WAN diferente.

No shaping baseado em aplicações, as três atribuições também têm de estar corretas: uma policy com Applications, a atribuição em Traffic shaping default e a opção ativada na regra de firewall. A seleção da opção, por si só, não atribui largura de banda.

O tráfego da aplicação para temporariamente

O SFOS 22.0 MR2 Build 546 corrige NC-178197, uma falha que podia interromper o tráfego de aplicações de forma intermitente quando era aplicada uma application-based bandwidth policy. Se este sintoma ocorrer no SFOS 22.0 GA ou MR1, deve verificar-se a versão do firmware e atualizar para MR2 ou para uma versão posterior aprovada antes de alterar as policies.

O Microsoft 365 ou a rede de convidados continuam problemáticos

O Microsoft 365 deve ser analisado separadamente para Teams, Exchange, SharePoint e OneDrive, em vez de garantir ou limitar indiscriminadamente toda a categoria. Na rede de convidados, deve verificar-se se o tráfego passa efetivamente pela regra prevista e se não está limitado apenas o download, mas também o upload.