Configurare Surfing e Network Traffic Quota su Sophos Firewall

Una Surfing quota limita il tempo Internet utilizzabile da un utente autenticato. Una Network traffic quota limita invece la quantità di dati trasferiti. Entrambe le policy vengono assegnate a un utente o a un gruppo e sono adatte, ad esempio, per aule di formazione, ospiti o pacchetti di utilizzo chiaramente definiti.

Per gli ospiti temporanei, creazione dell’account, validità, Captive Portal e pulizia vengono pianificati separatamente. Il ciclo di vita completo è descritto in Creare e gestire in sicurezza gli utenti guest su Sophos Firewall; questo articolo si concentra sulle quote.

Il percorso rapido per un’introduzione controllata è il seguente:

1. Stabilire se limitare il consumo di tempo, il volume di dati o entrambi.
2. Creare una nuova policy pilota in Profiles > Surfing quota oppure Profiles > Network traffic quota.
3. Assegnare la policy a un piccolo gruppo pilota in Authentication > Groups o a un singolo utente di test in Authentication > Users.
4. Autenticare nuovamente l’utente e verificare l’identità riconosciuta in Current activities > Live users.
5. Utilizzare per il test una regola firewall basata sull’utente con Log firewall traffic.
6. Aprire l’utente in Authentication > Users e controllare il consumo con View usage.
7. Testare il limite, il ciclo successivo e il rollback prima di aggiungere altri utenti.

⚠️ Reset user accounting azzera sia il tempo di navigazione consumato sia i contatori del traffico di rete. Si tratta di una modifica dello stato, non di un pulsante diagnostico generico. Prima dell’azzeramento si documentano utente, valori correnti, orario e motivo. Anche una quota di produzione condivisa non viene modificata direttamente; per i test si utilizza una policy pilota separata.

Scegliere la funzione adatta al requisito

Quattro funzioni dai nomi simili risolvono esigenze diverse:

• Access Time consente o blocca gli utenti in finestre orarie fisse. Non misura il consumo.
• Surfing quota assegna a un utente un credito di tempo consumabile per l’accesso a Internet.
• Network traffic quota assegna a un utente un credito di dati consumabile.
• Traffic Shaping limita o assegna priorità alla larghezza di banda. Una bassa velocità di trasmissione non è una quota dati.

Inoltre, una Web Policy offre l’azione Quota per l’accesso temporaneo a determinate categorie web. Questa Policy Quota appartiene alla logica del web proxy e non è la stessa funzione della Surfing Quota basata sull’utente descritta in questo articolo.

Una quota non crea né una regola firewall né un’identità utente. Il firewall deve riconoscere l’utente, il percorso di rete deve essere consentito e il traffico di test deve corrispondere alla regola prevista. Solo allora la quota può essere verificata in modo significativo.

Per la quota separata delle categorie web, Policy quota status mostra il tempo rimanente per utente e Web Policy in un periodo di 24 ore. Per un azzeramento autorizzato, selezionare lì gli utenti interessati e Reset. Prima documentare utente, policy e tempo rimanente; dopo verificare la schermata e una richiesta di test consentita. Non confondere questo azzeramento con Reset user accounting: una quota delle categorie web esaurita non giustifica la cancellazione dei contatori di navigazione e dati dell’utente.

Pianificare l’esempio e i prerequisiti

L’esempio continuo utilizza un piccolo gruppo pilota con due policy separate:

• Gruppo: Quota_Pilot
• Utente di test: 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

Si tratta volutamente di piccoli esempi di documentazione: ogni ciclo di 24 ore fornisce due ore di tempo Internet e ogni giorno 5000 MB di volume dati. Nomi, tempo, volume dati, ciclo e limite complessivo vengono adattati al contratto di utilizzo effettivo. I piccoli limiti di test non devono essere copiati in una policy esclusivamente produttiva senza verificarne l’impatto.

Prima della configurazione vengono controllati i punti seguenti:

1. L’utente pilota può accedere con il metodo di autenticazione previsto.
2. Nome utente e indirizzo sorgente compaiono in Current activities > Live users.
3. Per gli utenti AD, il campo Group in Authentication > Users è corretto.
4. Una regola firewall adatta e basata sull’utente consente il traffico di test e ha Log firewall traffic attivato.
5. Le assegnazioni esistenti di Surfing quota, Network traffic, Access time e Traffic shaping sono documentate.
6. Lo stato precedente e un utente di test alternativo sono noti.

Se l’utente non è visibile come Live User, si corregge prima l’autenticazione. Una quota non può attribuire in modo affidabile a un normale credito utente il traffico sconosciuto o gestito solo in base all’IP.

Creare una Surfing Quota

Una Surfing Quota misura il tempo Internet consumato. Nella guida di SFOS 22, lo stesso oggetto è documentato sia in Profiles > Surfing quota sia in Web > Surfing quotas. Si utilizza il percorso mostrato da WebAdmin nella build installata.

Si possono utilizzare anche le quote predefinite esistenti; una Surfing Quota esistente si apre con Edit. Considerare gli effetti su tutti gli utenti e gruppi assegnati.

Scegliere Cyclic o Non-cyclic

• Cyclic (repeat access): Il credito di tempo viene nuovamente reso disponibile in cicli ricorrenti. Il tempo non utilizzato non viene trasferito al ciclo successivo.
• Non-cyclic (one-time access): Il credito di tempo viene concesso una sola volta. Dopo averlo consumato, l’utente viene disconnesso.

Inoltre, Validity period limita il numero di giorni durante i quali la policy rimane valida. Maximum access time definisce il tempo utilizzabile. Quando si raggiunge il massimo, l’utente viene disconnesso anche se il periodo di validità della quota non è ancora scaduto.

Se a un utente si applicano più Surfing Quota, il firewall limita l’accesso non appena la prima di queste policy raggiunge il proprio limite. Per questo motivo occorre verificare insieme tutte le assegnazioni dirette e basate sui gruppi; una seconda policy più generosa non annulla un limite già raggiunto.

Unlimited per Maximum access time elimina solo il limite di tempo consumato, non la validità configurata separatamente. Per un uso illimitato concesso una sola volta per una settimana, scegliere ad esempio Non-cyclic (one-time access), impostare Validity period su 7 giorni e Maximum access time su Unlimited. È un requisito diverso da due ore per ciclo di 24 ore.

Per l’esempio pilota:

1. Aprire Profiles > Surfing quota > Add. Se la build mostra la funzione in Web > Surfing quotas, selezionare lì Add.
2. Impostare Name su Students_InternetTime.
3. Inserire, ad esempio, Pilot: 2h per 24h, Owner IT come Description.
4. Impostare Cycle type su Cyclic (repeat access).
5. Impostare Cycle hours su 24.
6. Definire consapevolmente il Validity period per il pilota oppure selezionare Unlimited solo se non serve una scadenza.
7. Impostare Maximum access time su 02:00.
8. Salvare con Save.

La policy salvata non è ancora attiva. Solo l’assegnazione a un utente o gruppo collega il credito di tempo a un’identità.

Inquadrare SurfingQuotaPolicy nell’API XML

Per le automazioni, la quota di tempo associata all’utente si chiama SurfingQuotaPolicy. Non è né una Network Traffic Quota né l’azione Quota di una Web Policy. La protezione dell’accesso, le operazioni esplicite di scrittura e la distinzione tra trasporto HTTP ed esito XML sono spiegate in Proteggere l’accesso all’API XML. Prima di una modifica, conservare il nome esatto dell’oggetto, tutti i valori salvati e le assegnazioni a utenti e gruppi; modificare solo una policy pilota separata.

Le documentazioni di riferimento XML per SFOS 22.0 e 23.0 elencano i campi seguenti. Completare la serializzazione per la build e l’operazione previste prima dell’invio:

• Name è obbligatorio: String, massimo 60 caratteri, senza virgole; UTF-8 è consentito. Questo vale anche per Delete Surfing Quota Policy. Description è facoltativo e limitato a 255 caratteri. La colonna Default non indica valori per questi campi; non dedurne un valore predefinito a runtime.
• CycleType compare nel modello come Cyclic/NonCyclic; per una richiesta occorrerebbe scegliere esattamente un valore confermato, non l’espressione con la barra. La tabella dei parametri indica però contemporaneamente String e l’intervallo 1–87840. Non attribuire questo intervallo contraddittorio a un altro campo e non interpretarlo come una codifica numerica del ciclo.
• CycleHours è descritto come String facoltativo per le ore del ciclo, senza un intervallo numerico. CycleMinutes è descritto come campo obbligatorio di tipo Integer con un massimo di quattro cifre. Da questo non deriva, in particolare, un intervallo confermato 0–59 per il campo. Il modello contiene inoltre PerDay con Days/Weekly/Monthly/Yearly, ma la tabella dei parametri non spiega questo campo. Pertanto, non convertire l’impostazione dell’interfaccia Cycle hours e la durata del ciclo del pilota in questi campi XML senza averle prima verificate.
• Per una validità finita, Validity è descritto come String con 0–3660 giorni. MaximumHours descrive il totale finito delle ore di navigazione come String con un massimo di sette caratteri; Minutes è il valore dei minuti aggiuntivi, di tipo String, nell’intervallo 0–59. La validità in giorni e il tempo consumabile in ore/minuti restano limiti separati; la validità non è un credito di tempo.

Un estratto di campi con valori finiti, esplicitamente non una richiesta completa o pronta per l’invio, mostra quest’ultima distinzione:

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

I valori di esempio rappresentano sette giorni di validità e due ore di tempo di navigazione complessivo, senza minuti aggiuntivi. Non mostrano l’implementazione completa del pilota ciclico dell’interfaccia «due ore ogni 24 ore». I campi del ciclo, l’assegnazione e l’operazione esplicita sono omessi intenzionalmente. I giorni e il credito di tempo vengono scelti in base al contratto di utilizzo approvato; per la serializzazione completa, confrontare prima API help della build installata con un oggetto pilota acquisito in sola lettura.

Per i valori illimitati, il modello mostra per Validity e MaximumHours il testo Unlimited/{Days}; righe separate della tabella per Validity e Maximum Hours indicano invece -11 e la stringa vuota ''. Questo non conferma che tali rappresentazioni siano intercambiabili, che i campi vuoti mantengano i valori esistenti o che Maximum Hours, con lo spazio, sia un tag XML. Inoltre, la descrizione delle ore non corrisponde al segnaposto {Days} in MaximumHours. Finché la rappresentazione del ciclo o la codifica di Unlimited restano da chiarire, non inviare richieste di scrittura e richiedere un chiarimento specifico per la build.

Verificare le risposte prima di un nuovo tentativo di scrittura

Per Add Surfing Quota Policy, Edit Surfing Quota Policy e Delete Surfing Quota Policy, operazione, codice XML e simbolo di riferimento vanno considerati insieme. Le documentazioni di riferimento per SFOS 22.0 e 23.0 contengono le stesse corrispondenze:

Message.* indica qui chiavi letterali non risolte della documentazione di riferimento, non messaggi verificati a runtime. Un esito positivo HTTP non equivale al successo dell’operazione XML. Anche un codice XML 200 non sostituisce la rilettura dell’oggetto di destinazione salvato: nome, ciclo, validità, ore e minuti devono corrispondere ai valori previsti e approvati. Solo dopo verificare l’assegnazione e convalidare l’effetto con View usage, una nuova autenticazione e il test limitato di consumo e del limite descritto in questo articolo; il solo salvataggio non dimostra che il limite venga applicato.

In caso di 500, 502, 504, di una risposta poco chiara o di un timeout, conservare prima la risposta ripulita dai dati sensibili e leggere lo stato effettivo dell’oggetto, prima di prendere in considerazione qualsiasi nuovo tentativo. In caso di 502, verificare se sotto il nome esatto sia già salvato l’oggetto desiderato o un altro oggetto; non passare automaticamente da Add a Edit. In caso di Delete con 504, controllare i riferimenti esistenti e le assegnazioni a utenti e gruppi, senza rimuovere regole dipendenti sulla base di supposizioni. Prima di un’eliminazione approvata, migrare le assegnazioni in modo controllato, verificare nuovamente le dipendenze e poi confermare che sia assente esattamente la policy pilota e che i servizi precedenti continuino a funzionare. Un codice di errore non dimostra né che lo stato sia rimasto invariato né che ripetere l’operazione sia sicuro. Un azzeramento dell’accounting non è un rollback per un aggiornamento tramite API o un’eliminazione.

Creare una Network Traffic Quota

Una Network Traffic Quota misura il volume di dati trasferito. Non limita la velocità. Un utente può quindi consumare il credito rapidamente o lentamente; se serve un limite di banda, si pianifica anche una policy di Traffic Shaping adeguata.

Limitare il traffico totale o separare upload e download

• Total network traffic: Un credito comune conteggia insieme upload e download.
• Individual network traffic (Upload & download): Upload e download ricevono limiti distinti. È adatto solo quando il requisito tratta realmente le due direzioni separatamente.

Sono disponibili anche due modelli di ciclo:

• Cyclic: Il credito si applica a ogni ciclo selezionato. Sono disponibili Day, Week, Month e Year. Il volume inutilizzato non viene trasferito.
• Non-cyclic: Il credito si applica a un singolo periodo di ciclo.

Quota per cycle definisce il credito per ciascun ciclo. Una Maximum quota opzionale aggiunge un limite complessivo e deve essere superiore alla quota del ciclo. Quando il limite del ciclo o quello complessivo è esaurito, il firewall disconnette l’utente. Per riconnetterlo prima del normale azzeramento serve Reset user accounting.

Per l’esempio pilota:

1. Aprire Profiles > Network traffic quota > Add.
2. Impostare Name su Students_DataVolume.
3. Inserire, ad esempio, Pilot: 5000 MB per day, Owner IT come Description.
4. Impostare Restriction su Total network traffic.
5. Impostare Cycle type su Cyclic.
6. Impostare Cycle period su Day.
7. Impostare Quota per cycle su 5000 MB.
8. Lasciare Maximum quota su Unlimited per questo esempio ricorrente. Se serve un limite complessivo, deve essere superiore alla quota del ciclo.
9. Salvare con Save.

I 5000 MB sono un valore di input per questo esempio, non un valore prescritto né un riferimento per la conversione. In una policy reale, il valore viene ricavato dal credito approvato e inserito nell’unità prevista da WebAdmin. Una policy con upload e download separati riceve invece valori propri e motivati per ciascuna direzione.

Sono disponibili anche policy Network Traffic predefinite; le policy esistenti si aprono con Edit. Per una Maximum quota finita, deselezionare la casella Unlimited corrispondente e inserire un valore superiore alla quota del ciclo. Dopo il salvataggio, riaprire e verificare i valori; non modificare una policy di produzione condivisa per una prova pilota.

Assegnare le quote a un gruppo o a un utente

Utilizzare un gruppo come metodo operativo normale

Per utenti con lo stesso credito, una policy di gruppo è più semplice da gestire rispetto a molti valori individuali:

1. Aprire Authentication > Groups.
2. Creare il gruppo Quota_Pilot oppure modificare un gruppo pilota chiaramente delimitato.
3. Selezionare Students_InternetTime in Surfing quota.
4. Selezionare Students_DataVolume in Network traffic.
5. Non modificare incidentalmente altri valori di Access Time, Traffic Shaping, Remote Access o del portale.
6. Salvare.
7. Autenticare nuovamente l’utente pilota e verificare il gruppo effettivamente utilizzato.

Gestire in sicurezza i gruppi utenti di Sophos Firewall spiega come interagiscono gruppi locali e importati, gruppo principale e override degli utenti. L’importazione AD vera e propria resta descritta in Collegare Active Directory a Sophos Firewall.

Verificare insieme l’override dell’utente e la selezione nella regola

In Authentication > Users, Surfing quota e Network traffic possono essere impostati diversamente per un singolo utente. La documentazione descrive però la priorità in modo diverso: la guida alla creazione degli utenti dà generalmente precedenza alla policy dell’utente, mentre la panoramica degli utenti la fa dipendere dalla selezione nelle regole e nelle policy. Indica i valori del gruppo quando è selezionato solo il gruppo e quelli dell’utente quando sono selezionati sia l’utente sia il suo gruppo. Non si deve quindi presumere che un override sia efficace incondizionatamente.

Per il pilota, documentare la selezione effettiva di utenti e gruppi nella regola o policy interessata e i due valori delle quote. Con un nuovo accesso, View usage e un flusso di test limitato, determinare quale valore si applica in quella build e su quel percorso. Se la schermata e il limite previsto non coincidono, interrompere il rollout; non ampliare una regola di produzione né riordinare i gruppi come soluzione rapida. Ripristinare poi le assegnazioni e la selezione precedenti e verificare nuovamente.

Se una modifica al gruppo non ha effetto su un utente, si controlla prima il relativo oggetto utente. Un override è adatto per un’eccezione documentata o un pilota, ma nel tempo può creare casi particolari nascosti. Per tornare alla policy di gruppo, si ripristina in modo controllato lo stato di ereditarietà precedente dell’utente.

In Active Directory conta solo la Main Group

Per gli utenti AD, Surfing Quota e Network Traffic non utilizzano le Other group memberships. Si applica la Main Group mostrata nel campo Group in Authentication > Users, oppure una policy esplicita assegnata all’utente.

L’ordine in Authentication > Groups > Reorder può cambiare la Main Group e quindi influire contemporaneamente su diverse policy. Non va modificato come soluzione rapida per una quota. Dopo una modifica pianificata del gruppo, si autentica nuovamente l’utente e si ricontrolla la Main Group.

I Clientless Users sono esclusi

I Clientless Users non supportano Surfing Quota né Network Traffic. Per un dispositivo fisso senza accesso utente, percorso di rete, pianificazione e, se necessario, Traffic Shaping vengono configurati in una regola firewall ristretta. Le quote utente non vengono utilizzate come sostituto basato sull’IP.

Verificare il consumo e convalidare il limite

View usage in WebAdmin

Per visualizzare il consumo, Sophos richiede una regola firewall basata sull’utente con Log firewall traffic attivato. Quindi:

1. Autenticare nuovamente l’utente pilota.
2. Controllare nome utente e indirizzo sorgente in Current activities > Live users.
3. Aprire Authentication > Users e selezionare l’utente pilota.
4. Aprire View usage.
5. Per Surfing Quota, controllare il tempo assegnato, la scadenza e il tempo Internet consumato.
6. Per Network Traffic, controllare Cycle renewal, upload, download e quota assegnata.
7. Generare un piccolo trasferimento di test consentito e ricontrollare la variazione.
8. Nel Log Viewer correlare utente, Source, Destination, Service, Firewall Rule ID, Action e timestamp.

La vista mensile mostra inoltre IP sorgente, inizio, fine, durata, upload e download. Tuttavia, un valore di consumo da solo non dimostra che siano stati utilizzati il percorso previsto e la regola corretta. Occorre quindi combinare View usage, Log Viewer e un flusso di test reale. Testare correttamente una regola Sophos Firewall spiega la verifica delle regole.

In View usage occorre distinguere le diverse aree:

• Policy information: Per AD, Group mostra solo la Main Group. Time allotted to user è il tempo di navigazione assegnato, Surfing quota expiry date la sua data di scadenza e Internet usage time il consumo dall’inizio o dall’ultimo azzeramento. Data transfer cycle renewal mostra il rinnovo di una quota dati ricorrente; per le quote non ricorrenti appare N.A..
• Usage information:Upload network traffic e Download network traffic mostrano il consumo totale e quello della sessione corrente. Qui Allotted indica la quota dati massima assegnata.
• Current cycle usage information: Per le quote ricorrenti, Cycle upload network traffic e Cycle download network traffic si riferiscono soltanto al ciclo giornaliero, settimanale, mensile o annuale corrente. Qui Allotted indica la quota del ciclo, non il massimo complessivo. Per consultare le sessioni passate, selezionare il mese desiderato nell’elenco di View usage.

Controllo dell’utente nello User Portal

La vista utente in Internet usage va distinta dalla vista amministrativa View usage:

• Policy information mostra il gruppo dell’utente, le ore di navigazione assegnate, la data di scadenza della Surfing Quota, la data di rinnovo del ciclo dati e il tempo Internet già consumato. Per un account guest viene mostrata anche la scadenza dell’account; la scadenza dell’account e il consumo della quota rispondono a domande diverse.
• Usage information mostra la quota dati assegnata, consumata e rimanente per upload e download.
• Monthly usage mostra il tempo di navigazione mensile e il trasferimento dati e aiuta a ricostruire il consumo precedente, anziché limitarsi alla quota residua attuale.

Non tutti gli utenti vedono tutti i campi: la visualizzazione dipende dal tipo di account e dalle policy assegnate. L’assenza di una scadenza dell’account guest per un account normale non dimostra quindi un errore della quota. Questa vista utente serve a controllare il consumo, non fornisce istruzioni per modificare la policy o azzerare i contatori.

Nello User Portal, in Internet usage, un utente può controllare, a seconda del tipo di account e della policy, il tempo di navigazione assegnato e consumato, il rinnovo del ciclo, nonché upload, download e credito rimanente. Questo riduce le richieste, ma non sostituisce la verifica amministrativa di assegnazione, Main Group, regola e log.

Testare il limite di consumo in modo controllato

Per un test del limite si utilizza una policy pilota separata con un credito deliberatamente piccolo ma sufficiente. Il test non deve coinvolgere un gruppo di produzione.

1. Documentare i valori iniziali in View usage.
2. Avviare un flusso di test HTTP o HTTPS chiaramente limitato.
3. Osservare il consumo e il Log Viewer durante il test.
4. Confermare che il raggiungimento del limite produca la disconnessione prevista.
5. Dopo la disconnessione, riaprire View usage e documentare il valore del contatore e l’orario.
6. Testare il ciclo regolare successivo o un azzeramento esplicitamente approvato.
7. Ripristinare successivamente la policy pilota e l’assegnazione precedente.

Utilizzare Reset user accounting in sicurezza

Reset user accounting azzera il tempo di navigazione e il consumo di traffico di rete dell’utente. Se una Network Traffic Quota è esaurita, questo azzeramento è necessario quando l’utente deve riconnettersi prima del ciclo regolare successivo. Questa procedura non consente di ripristinare i valori precedenti dei contatori; i valori acquisiti prima dell’azzeramento sono una prova, non un backup ripristinabile.

Un azzeramento controllato prevede:

1. Documentare utente, ticket, motivo, valori correnti delle quote e orario.
2. Verificare se è possibile attendere il cambio di ciclo regolare.
3. Assicurarsi che sia selezionato l’utente corretto.
4. Aprire l’utente in Authentication > Users.
5. Aprire View usage e conservare i valori iniziali.
6. Eseguire Reset user accounting solo con l’approvazione prevista.
7. Autenticare nuovamente l’utente e controllare i nuovi contatori.
8. Verificare un piccolo flusso di test, la Firewall Rule ID e i log.

L’azzeramento non corregge una Main Group errata, il mancato riconoscimento dell’utente o una policy firewall o web che blocca. Se queste cause non vengono chiarite prima, il problema si ripresenta nonostante i contatori azzerati.

Circoscrivere sistematicamente gli errori

La quota sembra non essere conteggiata

Prima si controlla in Current activities > Live users se sono visibili l’identità e l’indirizzo sorgente previsti. Poi si verifica che il traffico corrisponda a una regola firewall basata sull’utente con Log firewall traffic. Se manca il logging o il flusso utilizza un’altra regola, View usage può risultare incompleto.

Successivamente si confrontano la policy di gruppo, l’override utente e, per AD, la Main Group. La quota non viene ridotta precipitosamente solo per forzare un effetto visibile.

La quota di gruppo agisce solo su alcuni utenti

Non presumere che una policy esplicita dell’utente costituisca un override efficace senza verificare la selezione di utenti e gruppi. In Authentication > Users, controllare entrambi i campi delle quote e la Main Group, oltre alla selezione nella regola o policy effettivamente utilizzata. Per AD, le Other group memberships non vengono valutate. Dopo una modifica al gruppo, autenticare nuovamente l’utente.

L’utente viene disconnesso inaspettatamente

In View usage si controlla se è stato raggiunto Cycle quota, Maximum quota o Maximum access time. Poi si verificano separatamente Access Time, Web Policy, regola firewall e autenticazione. Captive Portal può comparire anche per credenziali errate o altri problemi di autenticazione; la quota non è automaticamente la causa. Configurare e testare Captive Portal su Sophos Firewall spiega l’intero percorso di accesso.

Il consumo non corrisponde alle aspettative

Si controlla se è configurato Total network traffic oppure limiti separati per upload e download. Poi si confrontano dettagli mensili, IP sorgente, Firewall Rule ID e trasferimento di test effettivo. Una Network Traffic Quota conta il volume di dati, non solo i download visibili nel browser; anche il traffico in background dell’utente autenticato può contribuire al consumo.

L’azzeramento aiuta solo per poco tempo

Se l’utente viene nuovamente disconnesso poco dopo l’azzeramento, si controllano valori della policy, ciclo, massimo, override utente e consumo effettivo. Il contatore non viene azzerato ripetutamente prima di aver compreso la causa.

Rollback e funzionamento

Un rollback controllato ripristina le assegnazioni precedenti delle policy. Un azzeramento dell’accounting già eseguito resta invece effettivo:

1. Ripristinare le precedenti assegnazioni Surfing e Network Traffic per l’utente o il gruppo pilota.
2. Per AD, autenticare nuovamente l’utente e controllare la Main Group.
3. Documentare View usage e il consumo attuale.
4. Azzerare l’accounting in modo controllato solo se concordato per il test.
5. Eseguire un piccolo flusso di test e controllare la Firewall Rule ID e i log.
6. Rimuovere le policy pilota solo quando non rimangono dipendenze di utenti o gruppi.
7. Aggiornare ticket, owner, limiti e risultato del test.

Durante il funzionamento, ogni quota condivisa necessita di un nome comprensibile, una Description, un owner e una motivazione documentata per ciclo, credito e limite complessivo. Le modifiche vengono convalidate con un utente pilota, un test positivo di consumo e un test negativo del limite.

Checklist operativa

• Il consumo di tempo e quello di dati sono stati pianificati separatamente.
• Surfing Quota e Network Traffic Quota hanno nomi e owner comprensibili.
• Cycle, Validity, Quota per cycle e Maximum sono motivati.
• Le policy sono assegnate al gruppo o all’utente corretto.
• Gli override utente sono stati verificati.
• Per AD, la Main Group è corretta; le Other group memberships non vengono date per scontate.
• I Clientless Users non vengono pianificati con quota utente.
• L’utente pilota appare come Live User.
• La regola firewall basata sull’utente registra il traffico di test.
• View usage, User Portal, Firewall Rule ID e consumo reale coincidono.
• Reset user accounting viene utilizzato solo con documentazione e approvazione.
• Lo stato precedente e il rollback sono documentati.

Domande frequenti