Configurar Surfing y Network Traffic Quota en Sophos Firewall

Una Surfing quota limita el tiempo de internet utilizable por un usuario autenticado. Una Network traffic quota, en cambio, limita el volumen de datos transferido. Ambas políticas se asignan a un usuario o grupo y son adecuadas, por ejemplo, para aulas de formación, invitados o paquetes de uso claramente definidos.

Para los invitados temporales, la creación de la cuenta, la validez, Captive Portal y la limpieza se planifican por separado. El ciclo de vida completo se explica en Crear y operar de forma segura usuarios invitados en Sophos Firewall; este artículo se centra en las cuotas.

La vía rápida para una introducción controlada es la siguiente:

1. Definir si se limitará el consumo de tiempo, el volumen de datos o ambos.
2. Crear una nueva política piloto en Profiles > Surfing quota o Profiles > Network traffic quota.
3. Asignar la política a un pequeño grupo piloto en Authentication > Groups o a un único usuario de prueba en Authentication > Users.
4. Volver a autenticar al usuario y comprobar la identidad reconocida en Current activities > Live users.
5. Utilizar para la prueba una regla de firewall basada en usuarios con Log firewall traffic.
6. Abrir el usuario en Authentication > Users y comprobar el consumo mediante View usage.
7. Probar el límite, el siguiente ciclo y el rollback antes de incorporar más usuarios.

⚠️ Reset user accounting restablece tanto el tiempo de navegación consumido como los contadores de tráfico de red. Es un cambio de estado, no un botón general de diagnóstico. Antes de un restablecimiento se documentan el usuario, los valores actuales, la hora y el motivo. Tampoco se modifica directamente una cuota de producción compartida; para las pruebas se utiliza una política piloto separada.

Elegir la función adecuada para el requisito

Cuatro funciones con nombres similares resuelven tareas diferentes:

• Access Time permite o bloquea usuarios durante franjas horarias fijas. No cuenta el consumo.
• Surfing quota proporciona a un usuario un crédito de tiempo consumible para el acceso a internet.
• Network traffic quota proporciona a un usuario un crédito de datos consumible.
• Traffic Shaping limita o prioriza el ancho de banda. Una velocidad de datos baja no es una cuota de datos.

Además, una Web Policy ofrece la acción Quota para el acceso temporal a determinadas categorías web. Esta Policy Quota pertenece a la lógica del proxy web y no es la misma función que la Surfing Quota basada en usuarios de este artículo.

Una cuota no crea una regla de firewall ni una identidad de usuario. El firewall debe reconocer al usuario, la ruta de red debe estar permitida y el tráfico de prueba debe coincidir con la regla esperada. Solo entonces puede comprobarse la cuota de forma significativa.

Para la cuota independiente de categorías web, Policy quota status muestra el tiempo restante por usuario y Web Policy dentro de un periodo de 24 horas. Para un restablecimiento autorizado, seleccionar allí los usuarios afectados y Reset. Antes, documentar el usuario, la política y el tiempo restante; después, comprobar la pantalla y una solicitud de prueba permitida. No confundir este restablecimiento con Reset user accounting: agotar una cuota de categorías web no justifica borrar los contadores de navegación y datos del usuario.

Planificar el ejemplo y los requisitos previos

El ejemplo continuo utiliza un pequeño grupo piloto con dos políticas separadas:

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

Son ejemplos de documentación deliberadamente pequeños: cada ciclo de 24 horas proporciona dos horas de internet y cada día 5000 MB de volumen de datos. Los nombres, el tiempo, el volumen de datos, el ciclo y el límite total se adaptan al acuerdo de uso real. Los límites pequeños de prueba no deben copiarse en una política exclusivamente productiva sin comprobar su impacto.

Antes de configurar se comprueban estos puntos:

1. El usuario piloto puede iniciar sesión con el método de autenticación previsto.
2. El nombre de usuario y la dirección de origen aparecen en Current activities > Live users.
3. En usuarios de AD, el campo Group de Authentication > Users es correcto.
4. Una regla de firewall adecuada y basada en usuarios permite el tráfico de prueba y tiene activado Log firewall traffic.
5. Están documentadas las asignaciones existentes de Surfing quota, Network traffic, Access time y Traffic shaping.
6. Se conocen el estado anterior y un usuario de prueba alternativo.

Si el usuario no aparece como Live User, primero se corrige la autenticación. Una cuota no puede asignar de forma fiable a un crédito de usuario normal el tráfico desconocido o tratado únicamente por IP.

Crear una Surfing Quota

Una Surfing Quota cuenta el tiempo de internet consumido. En la ayuda de SFOS 22, el mismo objeto aparece documentado tanto en Profiles > Surfing quota como en Web > Surfing quotas. Se utiliza la entrada que muestre WebAdmin en la compilación instalada.

También pueden utilizarse las cuotas predeterminadas existentes; una Surfing Quota existente se abre con Edit. Hay que considerar el impacto en todos los usuarios y grupos asignados.

Elegir Cyclic o Non-cyclic

• Cyclic (repeat access): El crédito de tiempo vuelve a estar disponible en ciclos recurrentes. El tiempo no utilizado no se transfiere al ciclo siguiente.
• Non-cyclic (one-time access): El crédito de tiempo se concede una sola vez. Tras consumirlo, el usuario se desconecta.

Además, Validity period limita el número de días durante los cuales la política es válida. Maximum access time define el tiempo utilizable. Cuando se alcanza el máximo, el usuario se desconecta aunque aún no haya expirado la validez de la cuota.

Si se aplican varias Surfing Quotas a un usuario, el firewall restringe el acceso en cuanto la primera de estas políticas alcanza su límite. Por ello, se revisan conjuntamente todas las asignaciones directas y basadas en grupos; una segunda política más generosa no anula un límite ya alcanzado.

Unlimited en Maximum access time elimina solo el límite de tiempo consumido, no la validez configurada por separado. Para un uso ilimitado durante una semana y concedido una sola vez, por ejemplo, seleccionar Non-cyclic (one-time access), establecer Validity period en 7 días y Maximum access time en Unlimited. Este requisito es distinto de dos horas por ciclo de 24 horas.

Para el ejemplo piloto:

1. Abrir Profiles > Surfing quota > Add. Si la compilación muestra la función en Web > Surfing quotas, seleccionar allí Add.
2. Establecer Name en Students_InternetTime.
3. Introducir, por ejemplo, Pilot: 2h per 24h, Owner IT como Description.
4. Establecer Cycle type en Cyclic (repeat access).
5. Establecer Cycle hours en 24.
6. Definir expresamente el Validity period del piloto o seleccionar Unlimited solo si no se necesita una fecha de caducidad.
7. Establecer Maximum access time en 02:00.
8. Guardar con Save.

La política guardada todavía no tiene efecto. Solo la asignación a un usuario o grupo vincula el crédito de tiempo con una identidad.

Contextualizar SurfingQuotaPolicy en la API XML

Para las automatizaciones, la cuota de tiempo basada en usuarios se denomina SurfingQuotaPolicy. No es una Network Traffic Quota ni la acción Quota de una Web Policy. La protección del acceso, las operaciones explícitas de escritura y la separación entre el transporte HTTP y el resultado XML se explican en Proteger el acceso a la API XML. Antes de realizar un cambio, conservar el nombre exacto del objeto, todos los valores guardados y las asignaciones de usuarios y grupos; editar únicamente una política piloto separada.

Las referencias XML para SFOS 22.0 y 23.0 indican los siguientes campos. Son datos documentados, no una serialización probada en un firewall:

• Name es obligatorio: String, como máximo 60 caracteres, sin comas; se permite UTF-8. Esto también se aplica a Delete Surfing Quota Policy. Description es opcional y está limitado a 255 caracteres. La columna Default no indica valores para estos campos; no deducir de ello ningún valor predeterminado en tiempo de ejecución.
• CycleType aparece en el modelo como Cyclic/NonCyclic; para una solicitud habría que elegir exactamente un valor confirmado, no la expresión con la barra. Sin embargo, la tabla de parámetros indica a la vez String y el intervalo 1–87840. No trasladar esta indicación contradictoria del intervalo a otro campo ni interpretarla como una codificación numérica del ciclo.
• CycleHours se describe como un String opcional para las horas del ciclo, sin intervalo numérico. CycleMinutes se describe como un campo obligatorio de tipo Integer con un máximo de cuatro dígitos. En particular, esto no confirma un intervalo de 0–59 para este campo. El modelo incluye además PerDay con Days/Weekly/Monthly/Yearly, pero la tabla de parámetros no explica este campo. Por tanto, no convertir sin comprobación previa el ajuste de la interfaz Cycle hours y la duración del ciclo del piloto a estos campos XML.
• Para una validez finita, Validity se describe como un String con 0–3660 días. MaximumHours describe el total finito de horas de navegación como un String de un máximo de siete caracteres; Minutes es el valor de minutos adicionales, expresado como un String en el intervalo 0–59. La validez en días y el tiempo consumible en horas/minutos siguen siendo límites separados; la validez no es un crédito de tiempo.

Un fragmento de campos con valores finitos, que expresamente no constituye una solicitud completa ni lista para enviar, muestra esta última separación:

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

Los valores de ejemplo representan siete días de validez y dos horas de tiempo total de navegación sin minutos adicionales. No muestran la implementación completa del piloto cíclico de la interfaz «dos horas por cada 24 horas». Los campos del ciclo, la asignación y la operación explícita se omiten deliberadamente. Los días y el crédito de tiempo se eligen a partir del acuerdo de uso aprobado; para la serialización completa, contrastar primero API help de la compilación instalada con un objeto piloto obtenido mediante una operación de lectura.

Para valores ilimitados, el modelo muestra para Validity y MaximumHours el texto Unlimited/{Days}; en cambio, las filas separadas de la tabla para Validity y Maximum Hours indican -11 y la cadena vacía ''. Esto no confirma que estas representaciones sean intercambiables, que los campos vacíos conserven los valores existentes ni que Maximum Hours, con un espacio, sea una etiqueta XML. Además, la descripción de las horas no encaja con el marcador de posición {Days} en MaximumHours. Mientras la representación del ciclo o la codificación de Unlimited sigan sin aclararse, no enviar ninguna solicitud de escritura y solicitar la aclaración específica para la compilación.

Comprobar las respuestas antes de un nuevo intento de escritura

En Add Surfing Quota Policy, Edit Surfing Quota Policy y Delete Surfing Quota Policy, la operación, el código XML y el símbolo de referencia deben considerarse conjuntamente. Las referencias para SFOS 22.0 y 23.0 contienen las mismas correspondencias:

Message.* identifica claves literales no resueltas; no debe tratarse como un texto de mensaje garantizado en tiempo de ejecución. Un resultado HTTP satisfactorio no implica que la operación XML haya tenido éxito. Tampoco un código XML 200 sustituye la lectura posterior del objeto de destino guardado: el nombre, el ciclo, la validez, las horas y los minutos deben coincidir con los valores previstos y aprobados. Solo entonces validar la asignación y su efecto mediante View usage, un nuevo inicio de sesión y la prueba limitada de consumo y límite de este artículo; guardar por sí solo no demuestra que se aplique la restricción.

Ante 500, 502, 504, una respuesta poco clara o un tiempo de espera agotado, conservar primero la respuesta depurada y leer el estado real del objeto antes de considerar cualquier reintento. Ante 502, comprobar si bajo el nombre exacto ya está guardado el objeto deseado u otro distinto; no cambiar automáticamente de Add a Edit. Ante Delete con 504, comprobar las referencias existentes y las asignaciones de usuarios y grupos; no eliminar reglas dependientes basándose en suposiciones. Antes de una eliminación aprobada, migrar las asignaciones de forma controlada, volver a comprobar las dependencias y confirmar después que falta exactamente la política piloto y que los servicios anteriores siguen funcionando. Un código de error no demuestra que el estado siga sin cambios ni que repetir la operación sea seguro. Un restablecimiento del accounting no permite revertir una actualización mediante la API ni una eliminación.

Crear una Network Traffic Quota

Una Network Traffic Quota cuenta el volumen de datos transferido. No limita la velocidad. Por tanto, un usuario puede consumir su crédito rápida o lentamente; si se necesita un límite de ancho de banda, se planifica además una política de Traffic Shaping adecuada.

Limitar el tráfico total o separar subida y descarga

• Total network traffic: Un único crédito común cuenta conjuntamente la subida y la descarga.
• Individual network traffic (Upload & download): La subida y la descarga reciben límites separados. Solo es adecuado cuando el requisito realmente trata ambas direcciones por separado.

También existen dos modelos de ciclo:

• Cyclic: El crédito se aplica a cada ciclo seleccionado. Están disponibles Day, Week, Month y Year. El volumen no utilizado no se transfiere.
• Non-cyclic: El crédito se aplica a un único periodo de ciclo.

Quota per cycle define el crédito de cada ciclo. Una Maximum quota opcional añade un límite total y debe ser superior a la cuota del ciclo. Cuando se agota el límite del ciclo o el límite total, el firewall desconecta al usuario. Para volver a conectarlo antes del restablecimiento ordinario se necesita Reset user accounting.

Para el ejemplo piloto:

1. Abrir Profiles > Network traffic quota > Add.
2. Establecer Name en Students_DataVolume.
3. Introducir, por ejemplo, Pilot: 5000 MB per day, Owner IT como Description.
4. Establecer Restriction en Total network traffic.
5. Establecer Cycle type en Cyclic.
6. Establecer Cycle period en Day.
7. Establecer Quota per cycle en 5000 MB.
8. Mantener Maximum quota en Unlimited para este ejemplo recurrente. Si se necesita un límite total, debe ser superior a la cuota del ciclo.
9. Guardar con Save.

Los 5000 MB son un valor de entrada para este ejemplo, no un valor obligatorio ni una ayuda de conversión. En una política real, el valor se deriva del crédito aprobado y se introduce en la unidad que espera WebAdmin. En cambio, una política con subida y descarga separadas recibe valores propios y justificados para cada dirección.

También hay políticas predeterminadas de Network Traffic; las políticas existentes se abren con Edit. Para una Maximum quota finita, desmarcar la casilla Unlimited correspondiente e introducir un valor superior a la cuota del ciclo. Después de guardar, volver a abrir y comprobar los valores; no modificar una política de producción compartida para una prueba piloto.

Asignar cuotas a un grupo o usuario

Utilizar un grupo como método operativo normal

Para usuarios con el mismo crédito, una política de grupo es más fácil de operar que muchos valores individuales:

1. Abrir Authentication > Groups.
2. Crear el grupo Quota_Pilot o editar un grupo piloto claramente delimitado.
3. Seleccionar Students_InternetTime en Surfing quota.
4. Seleccionar Students_DataVolume en Network traffic.
5. No modificar incidentalmente otros valores de Access Time, Traffic Shaping, Remote Access o del portal.
6. Guardar.
7. Volver a autenticar al usuario piloto y comprobar el grupo utilizado realmente.

Gestionar grupos de usuarios de Sophos Firewall de forma segura explica cómo interactúan los grupos locales e importados, el grupo principal y las excepciones de usuario. La importación de AD propiamente dicha se mantiene en Conectar Active Directory con Sophos Firewall.

Comprobar conjuntamente la excepción de usuario y la selección de la regla

En Authentication > Users, Surfing quota y Network traffic pueden definirse de forma diferente para un usuario individual. Sin embargo, la documentación describe la prioridad de forma distinta: la guía de creación de usuarios da prioridad general a la política del usuario, mientras que la vista general de usuarios la condiciona a la selección en reglas y políticas. Indica los valores del grupo cuando solo se selecciona el grupo y los del usuario cuando se seleccionan el usuario y su grupo. Por tanto, no debe suponerse que una excepción se aplica incondicionalmente.

Para el piloto, documentar la selección real de usuarios y grupos en la regla o política afectada y ambos valores de cuota. Con un inicio de sesión nuevo, View usage y un flujo de prueba limitado, determinar qué valor se aplica en esa compilación y ruta. Si la pantalla y el límite esperado no coinciden, detener el despliegue; no ampliar una regla de producción ni reordenar grupos como solución rápida. Después, restaurar las asignaciones y la selección de la regla anteriores y volver a comprobarlas.

Si un cambio de grupo no afecta a un usuario, primero se comprueba su objeto de usuario. Una excepción es adecuada para un caso documentado o un piloto, pero a largo plazo puede crear casos especiales ocultos. Para volver a la política de grupo, se restablece de forma controlada el estado de herencia anterior del usuario.

En Active Directory solo cuenta Main Group

Para los usuarios de AD, Surfing Quota y Network Traffic no utilizan Other group memberships. Se aplica la Main Group que aparece en el campo Group de Authentication > Users, o una política explícita del usuario.

El orden en Authentication > Groups > Reorder puede cambiar la Main Group y afectar al mismo tiempo a varias políticas. Por eso no se cambia como solución rápida para una cuota. Tras un cambio planificado de grupo, se vuelve a autenticar al usuario y se comprueba de nuevo la Main Group.

Clientless Users quedan excluidos

Los Clientless Users no admiten Surfing Quota ni Network Traffic. Para un dispositivo fijo sin inicio de sesión de usuario, la ruta de red, el horario y, si es necesario, Traffic Shaping se planifican en una regla de firewall restringida. Las cuotas de usuario no se utilizan como sustituto basado en IP.

Comprobar el consumo y validar el límite

View usage en WebAdmin

Para mostrar el consumo, Sophos requiere una regla de firewall basada en usuarios con Log firewall traffic activado. A continuación:

1. Volver a autenticar al usuario piloto.
2. Comprobar el nombre de usuario y la dirección de origen en Current activities > Live users.
3. Abrir Authentication > Users y seleccionar al usuario piloto.
4. Abrir View usage.
5. En Surfing Quota, comprobar el tiempo asignado, la caducidad y el tiempo de internet consumido.
6. En Network Traffic, comprobar Cycle renewal, subida, descarga y cuota asignada.
7. Generar una pequeña transferencia de prueba permitida y volver a comprobar el cambio.
8. Correlacionar en Log Viewer el usuario, Source, Destination, Service, Firewall Rule ID, Action y la marca de tiempo.

La vista mensual muestra además IP de origen, inicio, fin, duración, subida y descarga. Sin embargo, un valor de consumo por sí solo no demuestra que se hayan utilizado la ruta prevista y la regla correcta. Por eso se combinan View usage, Log Viewer y un flujo de prueba real. Probar correctamente una regla de Sophos Firewall explica la validación de reglas.

En View usage, hay que distinguir los distintos apartados:

• Policy information: En AD, Group muestra solo la Main Group. Time allotted to user es el tiempo de navegación asignado, Surfing quota expiry date su fecha de caducidad e Internet usage time el consumo desde el inicio o el último restablecimiento. Data transfer cycle renewal muestra la renovación de una cuota de datos recurrente; para cuotas no recurrentes aparece N.A..
• Usage information: Upload network traffic y Download network traffic muestran el consumo total y el de la sesión actual. Aquí, Allotted significa la cuota máxima de datos asignada.
• Current cycle usage information: En cuotas recurrentes, Cycle upload network traffic y Cycle download network traffic se refieren únicamente al ciclo diario, semanal, mensual o anual actual. Aquí, Allotted significa la cuota del ciclo, no el máximo total. Para consultar sesiones históricas, seleccionar el mes deseado en la lista de View usage.

Control del usuario en User Portal

La vista del usuario en Internet usage debe distinguirse de la vista administrativa View usage:

• Policy information muestra el grupo del usuario, las horas de navegación asignadas, la fecha de caducidad de Surfing Quota, la fecha de renovación del ciclo de datos y el tiempo de internet ya consumido. En una cuenta de invitado también aparece la caducidad de la cuenta; la caducidad de la cuenta y el consumo de la cuota responden a preguntas distintas.
• Usage information muestra la cuota de datos asignada, consumida y restante para subida y descarga.
• Monthly usage muestra el tiempo de navegación mensual y la transferencia de datos y ayuda a consultar el consumo anterior, no solo la cuota restante actual.

No todos los usuarios ven todos los campos: el tipo de cuenta y las políticas asignadas determinan lo que se muestra. Por tanto, que una cuenta normal no muestre la caducidad de una cuenta de invitado no demuestra un error de cuota. Esta vista del usuario permite controlar el consumo; no es una guía para modificar la política ni restablecer los contadores.

En User Portal, en Internet usage, un usuario puede comprobar, según el tipo de cuenta y la política, el tiempo de navegación asignado y consumido, la renovación del ciclo, así como la subida, la descarga y el crédito restante. Esto reduce consultas, pero no sustituye la validación administrativa de la asignación, Main Group, la regla y los registros.

Probar el límite de consumo de forma controlada

Para una prueba de límite se utiliza una política piloto separada con un crédito deliberadamente pequeño, pero suficiente. La prueba no debe afectar a ningún grupo de producción.

1. Documentar los valores iniciales en View usage.
2. Iniciar un flujo de prueba HTTP o HTTPS claramente limitado.
3. Observar el consumo y Log Viewer durante la prueba.
4. Confirmar que al alcanzar el límite se produce la desconexión esperada.
5. Tras la desconexión, volver a abrir View usage y documentar el valor del contador y la hora.
6. Probar el siguiente ciclo ordinario o un restablecimiento aprobado expresamente.
7. Restaurar después la política piloto y la asignación anterior.

Utilizar Reset user accounting de forma segura

Reset user accounting restablece el tiempo de navegación y el consumo de tráfico de red del usuario. Con una Network Traffic Quota agotada, este restablecimiento es necesario si el usuario debe volver a conectarse antes del siguiente ciclo ordinario. Este procedimiento no permite restaurar los valores anteriores de los contadores; los valores guardados previamente sirven como prueba, no como copia de seguridad restaurable.

Un restablecimiento controlado es el siguiente:

1. Documentar el usuario, el ticket, el motivo, los valores actuales de cuota y la hora.
2. Comprobar si puede esperarse al cambio de ciclo ordinario.
3. Asegurarse de que está seleccionado el usuario correcto.
4. Abrir el usuario en Authentication > Users.
5. Abrir View usage y conservar los valores iniciales.
6. Ejecutar Reset user accounting solo con la autorización prevista.
7. Volver a autenticar al usuario y comprobar los nuevos contadores.
8. Comprobar un pequeño flujo de prueba, la Firewall Rule ID y los registros.

El restablecimiento no corrige una Main Group incorrecta, una identificación de usuario ausente ni una política de firewall o web que bloquee. Si estas causas no se aclaran primero, el problema reaparece a pesar de los contadores restablecidos.

Delimitar los errores sistemáticamente

La cuota parece no contabilizarse

Primero se comprueba en Current activities > Live users si aparecen la identidad y la dirección de origen esperadas. Después se verifica que el tráfico coincida con una regla de firewall basada en usuarios y con Log firewall traffic. Si falta el registro o el flujo utiliza otra regla, View usage puede quedar incompleto.

A continuación se comparan la política de grupo, la excepción de usuario y, en AD, la Main Group. La cuota no se reduce precipitadamente solo para forzar un efecto visible.

La cuota de grupo solo afecta a algunos usuarios

No debe suponerse que una política explícita del usuario actúa como excepción sin comprobar la selección de usuarios y grupos. En Authentication > Users, revisar ambos campos de cuota y la Main Group, además de la selección en la regla o política que realmente coincide con el tráfico. En AD no se evalúan las Other group memberships. Tras un cambio de grupo, volver a autenticar al usuario.

El usuario se desconecta inesperadamente

En View usage se comprueba si se ha alcanzado Cycle quota, Maximum quota o Maximum access time. Después se revisan por separado Access Time, Web Policy, la regla de firewall y la autenticación. Captive Portal también puede aparecer por credenciales incorrectas u otros problemas de autenticación; la cuota no es automáticamente la causa. Configurar y probar Captive Portal en Sophos Firewall explica la ruta completa de inicio de sesión.

El consumo no coincide con lo esperado

Se comprueba si está configurado Total network traffic o límites separados de subida y descarga. Después se comparan los detalles mensuales, la IP de origen, la Firewall Rule ID y la transferencia de prueba real. Una Network Traffic Quota cuenta volumen de datos, no solo descargas visibles en el navegador; el tráfico en segundo plano del usuario autenticado también puede contribuir al consumo.

El restablecimiento solo ayuda brevemente

Si el usuario vuelve a desconectarse poco después del restablecimiento, se comprueban los valores de la política, el ciclo, el máximo, la excepción de usuario y el consumo real. El contador no se restablece repetidamente antes de comprender la causa.

Rollback y funcionamiento

Un rollback controlado restablece las asignaciones de políticas anteriores. Sin embargo, un restablecimiento del accounting ya ejecutado sigue vigente:

1. Restaurar la asignación anterior de Surfing y Network Traffic para el usuario o grupo piloto.
2. En AD, volver a autenticar al usuario y comprobar la Main Group.
3. Documentar View usage y el consumo actual.
4. Restablecer el accounting de forma controlada solo si se acordó para la prueba.
5. Ejecutar un pequeño flujo de prueba y comprobar la Firewall Rule ID y los registros.
6. Eliminar las políticas piloto solo cuando ya no exista ninguna dependencia de usuario o grupo.
7. Actualizar el ticket, el owner, los límites y el resultado de la prueba.

En funcionamiento, toda cuota compartida necesita un nombre comprensible, una Description, un owner y una justificación documentada para el ciclo, el crédito y el límite total. Los cambios se validan con un usuario piloto, una prueba positiva de consumo y una prueba negativa de límite.

Lista de comprobación operativa

• El consumo de tiempo y el consumo de datos se han planificado por separado.
• Surfing Quota y Network Traffic Quota tienen nombres y owners comprensibles.
• Cycle, Validity, Quota per cycle y Maximum están justificados.
• Las políticas están asignadas al grupo o usuario correcto.
• Se han comprobado las excepciones de usuario.
• En AD, la Main Group es correcta; no se presuponen Other group memberships.
• Los Clientless Users no se planifican con cuotas de usuario.
• El usuario piloto aparece como Live User.
• La regla de firewall basada en usuarios registra el tráfico de prueba.
• View usage, User Portal, Firewall Rule ID y el consumo real coinciden.
• Reset user accounting solo se utiliza con documentación y autorización.
• El estado anterior y el rollback están documentados.

Preguntas frecuentes