Configurar Application Traffic Shaping en Sophos Firewall

Application Traffic Shaping permite que Sophos Firewall priorice o limite aplicaciones individuales como Microsoft Teams, VoIP, OneDrive o servicios de copia de seguridad. El procedimiento completo basado en aplicaciones es el siguiente:

1. En System services > Traffic shaping, crear una política con Policy association > Applications.
2. En Applications > Application filter, configurar la detección de la aplicación deseada.
3. En Applications > Traffic shaping default, asignar la política a la aplicación o categoría.
4. En Rules and policies > Firewall rules, seleccionar el Application Filter y activar Apply application-based traffic shaping policy.

Una política con Policy association > Rules en el campo Shape traffic es una variante distinta: modela todo el tráfico que coincide con la regla de firewall, no solo la aplicación seleccionada en el Application Filter.

⚠️ Traffic Shaping no crea ancho de banda adicional. Distribuye un cuello de botella de forma más controlada. Si la conexión está saturada permanentemente, también deben revisarse la capacidad, las copias de seguridad, las sincronizaciones en la nube y otras fuentes de carga.

Traffic Shaping limita una velocidad de datos, no la cantidad total de datos transferidos. Para créditos de tiempo o datos consumibles se utilizan Surfing Quota y Network Traffic Quota.

Planificar los requisitos y el ancho de banda

Antes de configurar, se deben aclarar los siguientes puntos:

• Application Control es necesario para el shaping basado en aplicaciones. Forma parte de Web Protection y también se incluye en el paquete Standard Protection. El estado se puede comprobar en System > Administration > Licensing. En cambio, una política Rules no necesita detección de aplicaciones.
• El firewall detecta la aplicación afectada y el tráfico pasa por una regla de firewall conocida.
• El registro está activado para esta regla.
• Se sabe si el cuello de botella afecta a la subida, la descarga o ambas direcciones, y qué gateway WAN o ruta SD-WAN se utiliza.
• Se ha definido el efecto deseado: Guarantee reserva un ancho de banda mínimo y permite tráfico hasta el límite; Limit solo establece un máximo.

Sophos muestra los valores de shaping en KBps, mientras que las pruebas de velocidad suelen utilizar kbps o Mbit/s. 1 KBps equivale a 8 kbps. Por tanto, 100 Mbit/s son aproximadamente 12.500 KBps, y 20 Mbit/s, unos 2.500 KBps.

Se deben usar mediciones estables, no la velocidad anunciada por el proveedor. Si una conexión nominal de 100/20 Mbit/s solo ofrece de forma fiable 80/15 Mbit/s, se debe planificar con unos 10.000/1.875 KBps. Los valores superiores al cuello de botella real no permiten controlarlo correctamente.

En conexiones asimétricas, se debe activar Limit upload/download separately. Teams, VoIP, VPN y las copias de seguridad en la nube suelen ser los primeros servicios afectados cuando se satura la subida. Los valores globales de System services > Traffic shaping settings solo se aplican al tráfico saliente que el firewall reenvía a la zona WAN. En cambio, las políticas individuales de Traffic Shaping pueden aplicarse al tráfico reenviado tanto entrante como saliente. Además, QoS no se aplica al tráfico generado por el sistema del firewall, como las actualizaciones de patrones o las sincronizaciones de licencias.

Diferenciar los valores globales de las políticas individuales

En System services > Traffic shaping settings, Total available WAN bandwidth define la capacidad QoS conjunta de todos los enlaces WAN. Se introduce la suma del ancho de banda disponible de forma estable, en KBps, y no solo la velocidad contratada de un enlace. Show bandwidth usage muestra cómo se distribuye esta capacidad entre las prioridades. Estos valores globales solo afectan al tráfico WAN saliente reenviado que no coincide con una política individual de Traffic Shaping.

Con Optimize for real-time (VoIP), SFOS siempre prioriza primero el tráfico en tiempo real. Si la opción está desactivada, las políticas que garantizan ancho de banda reciben primero el ancho de banda comprometido y el tráfico en tiempo real utiliza el restante. Enforce guaranteed bandwidth activa para el tráfico sin política propia los valores Guarantee, Limit y Priority de 1 a 7 de la política predeterminada. Si Enforce guaranteed bandwidth está desactivado, este tráfico no recibe un ancho de banda mínimo garantizado, sino únicamente la capacidad que aún esté disponible. En Priority, 1 representa la prioridad más alta y 7 la más baja.

Estas opciones no deben activarse como solución general de rendimiento. Primero hay que documentar el ancho de banda real, las garantías existentes y la prioridad deseada. De lo contrario, garantías sobredimensionadas compiten por una capacidad que no existe físicamente.

Configurar Traffic Shaping basado en aplicaciones

El siguiente ejemplo prioriza el tráfico de hasta cuatro endpoints de vídeo de Teams activos simultáneamente en una pequeña sede con una conexión estable de aproximadamente 80/15 Mbit/s. En sus requisitos de ancho de banda para Teams, Microsoft recomienda aproximadamente 2.500 kbps de subida y 4.000 kbps de descarga por endpoint para una reunión de vídeo. Los valores del ejemplo reservan este requisito compartido, pero deben compararse con las mediciones propias y el número real de endpoints activos simultáneamente.

Crear una política de Traffic Shaping

En System services > Traffic shaping, crear una nueva política, por ejemplo con estos valores:

• Name: Teams Guarantee
• Policy association: Applications
• Rule type: Guarantee
• Limit upload/download separately: Enable
• Priority: 1 (prioridad 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 equivalen a 10 Mbit/s, y 2.000 KBps, a 16 Mbit/s. Con Shared, todas las aplicaciones o categorías a las que se asigna esta política comparten el mismo conjunto. Individual, en cambio, asigna el valor únicamente al objeto al que se asocia primero la política; por tanto, una política Individual no debe planificarse como plantilla reutilizable para varios objetos. No se deben repartir garantías elevadas entre demasiadas políticas, porque su suma debe ajustarse al ancho de banda realmente disponible. En este ejemplo, las garantías equivalen al requisito total recomendado de cuatro endpoints de vídeo de Teams. Cuando hay ancho de banda disponible, pueden utilizarlo hasta los límites superiores. Los límites de 12/40 Mbit/s reservan deliberadamente capacidad para otro tráfico en la conexión medida de 80/15 Mbit/s. Son valores iniciales, no requisitos universales de Teams.

En el procedimiento de la interfaz de usuario descrito aquí, las políticas de Traffic Shaping no se pueden editar después de crearlas. Esta limitación de la interfaz no significa que la API XML no documente una operación de actualización. Si más adelante se necesitan otros valores, primero se documentan todas las asignaciones, se crea una política de sustitución con un nombre nuevo y se migra inicialmente un ámbito limitado. Tras comprobarla, se migran las demás asignaciones; la política anterior solo se elimina cuando ya no queda ninguna referencia a ella. Para revertir el cambio, se vuelve a asignar la política anterior o None.

Política de QoS: distinguir el procedimiento de la interfaz del contrato de la API XML

Las referencias de la API XML para SFOS 22.0 y 23.0 documentan expresamente Add QoS policy / Update QoS policy para QoSPolicy y describen Add/Edit. Por tanto, hay una operación de API documentada, pero todavía no se ha confirmado un contrato de actualización ejecutable para el build instalado. Los datos siguientes explican la documentación; no son una plantilla de solicitud probada. El procedimiento seguro de sustitución mediante la interfaz sigue siendo la guía para realizar ajustes. El acceso, la operación explícita y la comprobación de las respuestas se explican en Usar la API XML de forma segura y evaluar las respuestas.

En el ejemplo, los campos de ancho de banda dependen de PolicyType y ImplementationOn; no se requieren todos simultáneamente para cada política:

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

En el ejemplo, cada ancho de banda Burstable debe ser mayor que su garantía correspondiente. Las ramas Individual solo mencionan User, Firewall y Application en sus comentarios; WebCategory aparece en Total, no en Individual. Esto no confirma una combinación Individual-WebCategory ni demuestra una prohibición en tiempo de ejecución. Además, ImplementationOn con Total/Individual no es el mismo campo que BandwidthUsageType con Individual/Shared; los tokens con el mismo nombre no son ajustes intercambiables.

El ejemplo y la tabla de parámetros no coinciden en todos los casos: el ejemplo indica 2–2560000 KB y la tabla, 2–10240000. De ello no se deduce un límite superior universal para el build. Para BandwidthUsageType, el ejemplo muestra Individual/Shared, mientras que la tabla indica Shared Bandwidth Usage Type con on/off. PolicyBasedOn utiliza tokens con nombre en el ejemplo, mientras que Policy Based On se describe en la tabla como un entero con valor predeterminado 0. Aquí no se deducen de ello ni la correspondencia de los tokens ni un valor predeterminado seguro en caso de omisión.

Los detalles de programación también tienen dos representaciones que no se han conciliado de forma inequívoca: el ejemplo muestra SchedulebasedPolicyRuleList con Rule, DetailId, PolicyType, los campos condicionales de ancho de banda y Schedule; además, DetailId figura en el objeto de política. La tabla indica Implementation On como un array con 6/7, Policy Type como un array con 8/11, las listas de ancho de banda bandwidthlist, grntdbandwidthlist, burstbandwidthlist, upbandwidthlist, downbandwidthlist, grntdupbandwidthlist, grntddownbandwidthlist, así como qosdetailnamelist y ScheduleDetail. Aquí no se establece una correspondencia entre las enumeraciones numéricas y los tokens con nombre; no se hacen suposiciones sobre el orden, la identidad de los detalles ni el comportamiento de actualización u omisión.

Antes de realizar un cambio mediante la API, API help del build instalado debe aclarar estos límites, nombres de campos y estructuras de programación aún sin resolver. Mientras el contrato no esté claro, no se debe construir una solicitud de escritura a partir del ejemplo. Guardar el estado previo, las asignaciones y los detalles de programación; después de un cambio autorizado, volver a leer el objeto y los detalles por separado y comprobar el efecto del shaping en el intervalo de tiempo afectado. La referencia enumera los estados XML 200, 500 y 502 tanto para Add como para Update. La fuente original remite a los símbolos sin resolver Message.QOSAddSuccess, Message.QOSAddFail, Message.QOSEditSuccess, Message.QOSEditFail y Message.QOSRecordExist; los mensajes no figuran en el texto extraído. Estos símbolos no son textos de mensajes confirmados aquí ni códigos HTTP. Un estado por sí solo no confirma ni todos los detalles ni el efecto. En caso de discrepancias, guardar la respuesta y el estado actual y no repetir la operación a ciegas; restaurar únicamente el cambio propio al estado guardado.

Crear un Application Filter

En Applications > Application filter, crear un filtro que solo contenga el tráfico deseado:

1. Asigne un nombre como Microsoft Teams.
2. Añada una regla de Application.
3. Busque microsoft teams en Smart Filter.
4. Seleccione las aplicaciones de Teams pertinentes y utilice la acción Allow.
5. Guarde la regla de Application con Save y, a continuación, guarde también Application Filter con Save.

Microsoft 365 no debe tratarse por defecto como una única aplicación. Teams, Exchange, SharePoint y OneDrive generan tráfico distinto y al principio deben observarse por separado. Si el objetivo es la detección y el bloqueo, no el ancho de banda, se puede consultar Configurar y probar Application Control en Sophos Firewall.

Asignar la política a la aplicación

En Applications > Traffic shaping default, buscar Microsoft Teams o la categoría de aplicaciones adecuada. Una categoría se abre directamente con Edit. Para una aplicación individual, primero se despliega la categoría con Expand y después se selecciona Edit en la aplicación. A continuación se elige Teams Guarantee y se confirma con Save.

Una política aplicada a una aplicación individual tiene prioridad sobre una política aplicada a su categoría. Cuando coinciden varios niveles simultáneamente, la descripción general de Shaping indica el siguiente orden: aplicación, categoría de aplicación, categoría web, usuario, grupo y, por último, regla de firewall. Si existe una Rules-Policy adicional, debe seguir teniéndose en cuenta la siguiente discrepancia en la documentación.

La asignación en Traffic shaping default todavía no activa el control de tráfico basado en aplicaciones; para ello también se requiere Apply application-based traffic shaping policy en la regla de firewall que realmente coincida con el tráfico. Sin embargo, cuando se establece simultáneamente una política de tipo Rules, la documentación no es inequívoca: para Traffic shaping default se describe una anulación por parte de la regla de firewall, mientras que la descripción general del control de tráfico sitúa las aplicaciones por delante de las reglas de firewall. De ello no puede deducirse una excepción respaldada de forma fiable que dependa del estado del interruptor. Para comenzar con una configuración que pueda comprobarse de forma inequívoca, se utiliza un solo nivel de control de tráfico y se verifica su efecto mediante la Application ID detectada, la regla asignada y la tasa de transferencia medida. Si se combinan niveles, no debe darse por supuesto su efecto de precedencia sin comprobarlo.

Activar la regla de firewall

En Rules and policies > Firewall rules, abrir la regla por la que pasa realmente el tráfico de Teams. En la sección Other security features:

1. En Identify and control applications (App control), seleccionar el filtro Microsoft Teams.
2. Activar Apply application-based traffic shaping policy.
3. Guardar la regla y generar tráfico.

La política de tipo Applications no se selecciona en el campo Shape traffic, sino que procede de Traffic shaping default. La descripción general del control de tráfico indica el orden aplicación, categoría de aplicaciones, categoría web, usuario, grupo y, por último, regla de firewall. Debido a la indicación diferente sobre la anulación de Traffic shaping default, cuando hay políticas asignadas simultáneamente, este orden constituye una indicación de la documentación y no un efecto de precedencia confirmado aquí. Solo deben combinarse varios niveles de forma deliberada y comprobarse con tráfico real.

El orden de las reglas sigue siendo decisivo: si el tráfico ya coincide con una regla más general situada más arriba, no se aplican ni el filtro ni el control de tráfico de la regla posterior.

Limitar una aplicación individual o garantizar ancho de banda a una categoría

Para establecer únicamente un límite máximo, el procedimiento es el mismo, pero Rule type se establece en Limit. Un ejemplo para una aplicación de Zoom ya detectada es una política Zoom Limit con Policy association > Applications, Rule type > Limit, Priority > 1, Limit upload/download separately > Disable, Limit > 1000 (KBps) y Bandwidth usage type > Shared. 1000 KBps equivalen a 8 Mbit/s; este valor inicial elegido libremente no es una recomendación de Zoom y debe ajustarse a la capacidad medida de la conexión y a la calidad de llamada deseada. Aquí, Disable significa que no se establecen límites separados de subida y bajada, no que el control de tráfico esté desactivado. En Applications > Traffic shaping default, se abre Conferencing con Expand y se asigna la política en Zoom meetings mediante Edit. En el Application Filter, se selecciona la aplicación correspondiente mediante Smart Filter con Zoom. Se guardan la regla del filtro, el filtro y la regla de firewall; en la regla de firewall siguen siendo necesarios el filtro correspondiente y Apply application-based traffic shaping policy. Con suficiente tráfico ofrecido, se comprueba si la tasa de transferencia se mantiene en el límite elegido y si la Application ID detectada realmente corresponde a Zoom.

Para una garantía compartida de toda una categoría de aplicaciones, la política de tipo Applications se asigna directamente a la categoría. Por ejemplo, se abre Remote Access en Traffic shaping default mediante Edit y se asigna una política Guarantee con Shared. En el Application Filter, se crea una regla con Category > Remote access; después se guardan la regla y el filtro, y en la regla de firewall que coincida con el tráfico se establece el filtro y se activa el interruptor de control de tráfico. Todas las aplicaciones cubiertas por esta política comparten el conjunto de ancho de banda; no recibe cada una la garantía completa. La garantía y el límite se eligen en función de la capacidad disponible y de las sesiones simultáneas realmente necesarias. La asignación a una categoría no permite aplicaciones de acceso remoto bloqueadas previamente; las restricciones de acceso existentes siguen siendo determinantes.

Traffic Shaping por regla para una regla completa

Si todo el tráfico de una regla de firewall claramente delimitada debe recibir los mismos valores, una política Rules es más sencilla:

1. En System services > Traffic shaping, crear una política con Policy association > Rules.
2. En Rules and policies > Firewall rules, abrir la regla afectada.
3. En Shape traffic, seleccionar la política Rules.
4. No activar Apply application-based traffic shaping policy, salvo que se utilicen políticas Applications adicionales.

Un Application Filter no restringe automáticamente una política de tipo Rules a esa aplicación. Para ello, la propia regla de firewall debe estar delimitada estrictamente mediante el origen, el destino y los servicios, o bien debe utilizarse el procedimiento basado en aplicaciones. DSCP marking tampoco sustituye al control de tráfico: DSCP marca los paquetes para los dispositivos posteriores, mientras que la política de control de tráfico en el firewall garantiza o limita el ancho de banda.

De este modo, una política de tipo Rules también puede controlar el tráfico de conexiones VPN, hosts individuales, grupos de hosts o servicios. Para el tráfico procedente de una VPN, se utiliza Source zone > VPN en la regla correspondiente; para hosts IP o MAC, o grupos de hosts, se seleccionan los objetos deseados en Source networks and devices. Los servicios delimitan los puertos y protocolos. Estos criterios determinan qué tráfico coincide con la regla antes de que actúe Shape traffic. No debe restringirse de forma irreflexiva una regla existente en producción solo para realizar una prueba de control de tráfico; primero se comprueba qué conexiones permitidas dejarían de coincidir con la regla como consecuencia de ese cambio.

Aplicar Traffic Shaping a otros objetos

Policy association determina ya durante la creación dónde puede seleccionarse una política: Applications, Web categories, Users o Rules. En el procedimiento de la interfaz, la política no puede convertirse después a otro tipo; de ello no se deduce una migración de tipo mediante la API. Una programación opcional limita su vigencia temporal, pero no sustituye ni la asignación al objeto ni la prueba de funcionamiento. Durante la creación, Add schedule se encuentra más abajo en la política: mediante Add se establecen los horarios deseados y, después, se guarda la política con Save. Con o sin programación, la política solo entra en vigor al asignarla a una aplicación, categoría, usuario o regla. En caso de un fallo relacionado con el horario, se comprueba además si la prueba se realiza dentro del intervalo de tiempo configurado.

Aplicar shaping a categorías web

Para un sitio web o una categoría, se crea una política con Policy association > Web categories y se asigna a la categoría correspondiente en Web > Categories. La categoría debe figurar en una Web Policy efectiva. En la regla de firewall que realmente coincida con el tráfico, se activan esta Web Policy y Apply web category-based traffic shaping. Una asignación a una categoría guardada, por sí sola, todavía no controla ningún tráfico.

Para un único sitio web concreto, una categoría propia resulta más fácil de verificar que una categoría existente amplia. Como ejemplo, se crea una política Website Limit con Web categories, Limit, Priority > 1, Limit upload/download separately > Disable, Limit > 1000 (KBps) y Shared. Los 8 Mbit/s son un límite máximo de ejemplo ajustable, no una directriz general para la web; todas las categorías asignadas a esta política comparten el conjunto de ancho de banda. Una política de tipo Limit no garantiza un ancho de banda mínimo.

1. En Web > Categories > Add, crear una categoría como Example Website y seleccionar Classification > Productive, la política Website Limit y Configure category > Local.
2. En Domain/keyword, añadir el dominio de ejemplo www.example.com con el botón de signo más y guardar con Save. En producción, se sustituye por el dominio realmente deseado. Una palabra clave adicional como example solo tiene sentido si también se pretende una asignación más amplia por palabra clave; no debe copiarse a ciegas de un ejemplo.
3. En Web > Policies, abrir la Web Policy efectiva y añadir una regla adecuada con Add. En Activities > Show only > Web categories, seleccionar la nueva categoría e incorporarla con Apply selected items. Antes de Save, comprobar la autorización de acceso existente y el orden de las reglas; el control de tráfico no es motivo para permitir sitios web bloqueados.
4. En la regla de firewall que realmente coincida con el tráfico, seleccionar esta Web Policy en Security features > Web filtering, activar Apply web category-based traffic shaping y guardar la regla.

A continuación, comprobar con un sitio web permitido de la categoría si se aplican la regla de firewall y la categoría web esperadas, y si la tasa de transferencia se mantiene en el límite cuando hay suficiente tráfico. Un sitio web que no pertenezca a la categoría sirve como prueba de contraste. Si se produce una coincidencia inesperada, se comprueban la asignación de dominios y palabras clave, el orden de las reglas de la Web Policy y otras asignaciones de control de tráfico.

Asignar categorías web mediante la API XML

Para las asignaciones recurrentes de categorías, la referencia XML describe WebFilterCategory con QoSPolicy. El campo hace referencia a la política de ancho de banda existente; para este procedimiento, debe corresponder a Web categories. No es una Web Policy ni una acción Allow/Block. Antes de escribir, guardar el contenido de la categoría, la asignación de shaping anterior y las referencias de Web Policy. El acceso, la operación explícita, el contrato del build y el estado XML se explican en Usar la API XML de forma segura y evaluar las respuestas. Los datos siguientes describen relaciones entre objetos según la documentación; no son una plantilla de solicitud ejecutable ni probada en un build de firewall.

En ConfigureCategory, Local utiliza la jerarquía DomainList/Domain y KeywordList/Keyword; External utiliza URLList/URL para una lista externa de categorías. La URL de una lista externa no es el dominio de la empresa cuyo tráfico se desea limitar. Comprobar el origen, la actualización y el contenido de la lista, y no mezclar las dos vías de entrada sin verificarlas previamente. La tabla también incluye 0, sin explicar claramente su significado; no debe deducirse de ello una alternativa a las dos vías identificadas por nombre.

Classification clasifica la categoría, pero no permite ni bloquea el acceso. La tabla de enumeraciones indica Productive, Unproductive, Acceptable y Objectionable, mientras que la descripción utiliza en parte otras denominaciones. No utilizar nombres de clasificación traducidos como valores de la API; si el contrato no está claro, consultar primero API help del build instalado y no realizar escrituras. La tabla de referencia identifica QoSPolicy como campo obligatorio con un máximo de 50 caracteres y sin comas; el ejemplo muestra None. Este ejemplo no acredita un valor predeterminado en tiempo de ejecución ni confirma que omitir el campo conserve o elimine la asignación anterior. Para el caso de shaping, comprobar la política existente con la asociación adecuada y el nombre con el que está realmente guardada.

Incluso después de una asignación mediante la API, sigue siendo necesario completar todo el procedimiento de la interfaz descrito arriba: la categoría debe utilizarse en la Web Policy efectiva, y tanto esta política como Apply web category-based traffic shaping deben estar configuradas en la regla de firewall con la que realmente coincida el tráfico. La clasificación, el contenido de la categoría, el acceso y el ancho de banda siguen siendo decisiones independientes. Comprobar con un sitio web permitido de la categoría, una prueba de contraste sin coincidencia y un destino que siga bloqueado que solo se haya modificado la asignación de ancho de banda prevista. Una categoría guardada todavía no demuestra que el shaping sea efectivo.

Las respuestas de categoría varían según la operación. Los valores siguientes son códigos de estado XML y símbolos de referencia sin resolver, conservados sin cambios; no son códigos HTTP ni textos de mensajes confirmados aquí:

Ante las respuestas relativas a los detalles, volver a leer por separado el objeto de categoría y cada conjunto necesario de dominios, palabras clave o listas: un código XML 2xx no significa automáticamente que se hayan guardado todos los detalles. El nombre de símbolo compartido por los dos códigos de éxito de Add no explica la diferencia entre ellos. Los símbolos con «MaxFive» no acreditan un límite actual universal de cinco entradas; consultar el alcance permitido en la ayuda del build. Antes de eliminar, comprobar las referencias de Web Policy y, después, determinar qué categorías permanecen realmente; en una selección múltiple, no dar por hecho que todas las eliminaciones se hayan realizado correctamente.

Antes de cada reintento, guardar la respuesta, el estado actual y el Audit Trail. Después, comparar el contenido de la categoría, QoSPolicy y las referencias con el estado previo documentado y planificar únicamente la corrección propia que aún sea necesaria. No volver a crear, actualizar o eliminar a ciegas un cambio guardado parcialmente. Para revertirlo, restaurar únicamente la asignación propia de categoría/política al estado guardado; para los valores de ancho de banda modificados, la política de sustitución sigue siendo el procedimiento seguro en esta guía operativa de la interfaz. La operación de actualización de QoSPolicy documentada debe distinguirse de este procedimiento y está sujeta a los contratos de API aún sin aclarar que se han explicado anteriormente.

Usuarios, grupos y reglas WAF

Una política con Policy association > Users se asigna en Authentication > Users o Authentication > Groups. En la regla de firewall, se activa Match known users y se seleccionan los usuarios o grupos correspondientes; la identidad realmente detectada debe coincidir con esta selección. Para una regla WAF, en cambio, se asigna una política Rules en Advanced settings > Traffic shaping de la regla con Action > Protect with web server protection.

Cuando hay varios niveles, la descripción general del control de tráfico indica el orden aplicación, categoría de aplicaciones, categoría web, usuario, grupo y, por último, regla de firewall. La indicación diferente para Traffic shaping default explicada anteriormente debe seguir teniéndose en cuenta cuando se combinan asignaciones. Por ello, se comprueba qué política actúa mediante un flujo real, el usuario detectado o la Application ID y la regla que realmente coincida con el tráfico.

Comprobar el efecto y ajustar la política de forma segura

Después del cambio no basta con ejecutar una prueba de velocidad. Se debe comprobar si:

• El tráfico coincide con la regla de firewall esperada.
• Los registros de Application Control muestran la aplicación o el Application ID esperados.
• Informes como Top Applications y los contadores de reglas confirman la asignación prevista.
• La dirección afectada está realmente saturada durante la prueba.
• El ancho de banda, la latencia, la pérdida de paquetes o la calidad de las llamadas cambian según lo previsto.
• La prueba utiliza el mismo gateway WAN y la misma ruta SD-WAN que el tráfico de producción.
• Los usuarios de servicios en tiempo real confirman en la práctica las mediciones técnicas.

Para una comparación fiable antes y después, se debe usar el mismo origen, destino, dirección y, si es posible, periodo. La guía Comprobar el rendimiento de Sophos Firewall con iPerf y Speedtest muestra métodos de medición adecuados. Si hay varias conexiones, también resulta útil Comprobar el enrutamiento SD-WAN de Sophos Firewall para Reply Packets y System Traffic.

Para realizar ajustes en la interfaz, se crea una nueva versión de la política con valores modificados de forma prudente, en lugar de editar la política existente. Primero se asigna a una aplicación, categoría o regla de alcance delimitado, se observan los registros y los comentarios de los usuarios, y la política anterior solo se elimina tras una comprobación satisfactoria. Se deberían documentar el propósito, la regla afectada, los valores, el responsable y la fecha de revisión.

Cuando Traffic Shaping no funciona como se espera

No se detecta la aplicación

Primero se debe comprobar que se haya seleccionado el Application Filter correcto en la regla de firewall por la que pasa realmente el tráfico. Para los servicios en la nube amplios o cifrados, la clasificación debe confirmarse en el registro de Application Control mediante el Application ID detectado.

El shaping no muestra diferencias

Si la conexión no está saturada durante la prueba, no hay ningún cuello de botella visible que controlar. Otras causas frecuentes son valores superiores al ancho de banda real, la dirección equivocada, una regla de firewall más general situada arriba o una ruta SD-WAN distinta.

Para el shaping basado en aplicaciones, también deben ser correctas las tres asignaciones: una política con Applications, la asignación en Traffic shaping default y la opción activada en la regla de firewall. La opción por sí sola no asigna ancho de banda.

El tráfico de aplicaciones se detiene de forma intermitente

SFOS 22.0 MR2 Build 546 corrige NC-178197, un error que podía detener de forma intermitente el tráfico de aplicaciones al aplicar una política de ancho de banda basada en aplicaciones. Si este síntoma aparece en SFOS 22.0 GA o MR1, se debe comprobar la versión del firmware antes de rediseñar las políticas y actualizar a MR2 o a una versión posterior aprobada.

Microsoft 365 o la red de invitados sigue dando problemas

Microsoft 365 debe analizarse por separado para Teams, Exchange, SharePoint y OneDrive, en lugar de garantizar o limitar toda la categoría indiscriminadamente. En la red de invitados se debe comprobar que el tráfico coincida realmente con la regla prevista y que tanto la subida como la descarga estén limitadas cuando sea necesario.