Gerarchie
I sette sostantivi di una configurazione Warden, e come si intrecciano in una sola policy per client.
Il modello
La configurazione di Warden ha sette entità. Dividile in due compiti e l’intero modello va a posto.
Ogni configurazione Warden è costruita con sette sostantivi: profiles, devices, groups, subnets, schedules, blocklists e admin rules. Si separano nettamente lungo una sola linea:
- Identità — chi è questo client? Device, group e subnet sono tre modi di riconoscere un client e legarlo a un profilo.
- Policy — cosa riceve quel client? Blocklist e admin rule sono il materiale grezzo del filtraggio; un profilo le raccoglie in un unico comportamento con nome.
Un profilo è la cerniera tra i due. Le entità di identità puntano a un profilo; un profilo punta alla policy che applica. Nient’altro si collega — ed è questo che tiene il modello piccolo abbastanza da starti in testa.
La mappa
I profili sono il centro. L’identità entra da sinistra, la policy pende a destra, e uno schedule può scambiare il profilo per un po’.
Identità · chi è il client?
- device
- group
- subnet
- default_profile
Policy · cosa applica?
- blocklists
- admin_rules
Leggila in un fiato: un device, un group o una subnet puntano a esattamente un profilo — e se non combacia nessuno, il default_profile del server intercetta il client. Quel profilo compone una o più blocklist e admin rule. Uno schedule è l’unico pezzo consapevole del tempo: scambia un profilo diverso per un device o gruppo abbinato durante la sua finestra, poi restituisce il controllo.
I ruoli
A cosa serve ogni entità, da che lato della linea identità/policy sta, e quanti profili tocca.
| Entità | Ruolo | Strato | Verso un profilo |
|---|---|---|---|
| Profile | Il bundle di policy: blocklist, admin rule, la risposta di blocco, record locali opzionali | Policy — il hub | è il hub |
| Device | Un client, fissato per IP e/o MAC | Identità | punta a 1 (opzionale) |
| Group | Un insieme con nome di device che condividono un profilo | Identità | 1 profilo, molti device |
| Subnet | Un range CIDR con profilo di fallback (vince il prefisso più lungo) | Identità | 1 profilo, molti CIDR |
| Schedule | Uno scambio a tempo verso un profilo diverso, per un device o gruppo | Overlay | scambia verso 1 |
| Blocklist | Un feed esterno di domini da bloccare | Sorgente di policy | referenziata da molti |
| Admin rule | Una regola tipizzata — allow, deny o regex | Sorgente di policy | referenziata da molti |
Qualche fatto di cardinalità che la tabella comprime:
- Un device punta a un profilo (opzionale) e può appartenere a molti group.
- Un group ha un profilo e molti device; una subnet ha un profilo e molti CIDR.
- Una blocklist o una admin rule è referenziata da molti profili — scrivila una volta, iscriviti da qualsiasi parte.
- Uno schedule ha esattamente un bersaglio (un device o un group, mai entrambi) e un profilo di overlay.
L’identità non porta mai policy
La divisione tra identità e policy è deliberata — ed è il motivo per cui un profilo può governare una dozzina di client senza duplicazione.
Le entità di identità — device, group, subnet — non contengono mai regole di filtraggio inline. Puntano soltanto a un profilo. Tutta la policy vera (quali liste, quali regole, cosa rispondere quando una query è bloccata) vive sul profilo. Quella separazione è ciò che permette a un singolo profilo kids di governare un tablet, un laptop e un’intera VLAN senza tre copie dello stesso set di regole: cambi il profilo una volta e ogni client legato ad esso si aggiorna.
L’unica cucitura dove un’entità di identità tocca la policy in modo diretto sono gli allow_rules / deny_rules di un device — un’eccezione per singolo device per un dominio isolato che non merita un profilo tutto suo. Anche lì il device referenzia admin rule tipizzate; non incorpora mai una blocklist.
Dove prosegue ogni entità
Questa pagina è la mappa. Ogni sostantivo ha la sua guida con lo schema completo, la CLI e gli esempi.
- Profiles — il bundle di policy a cui punta ogni altra entità.
- Devices, Groups, Subnets — i tre strati di identità.
- Schedules — overlay di profilo a tempo.
- Blocklists e Admin rules — le sorgenti di policy che un profilo compone.
- Il riferimento config.toml completo, campo per campo.
Vedi anche
Hai appena visto come sono cablate le entità. Per l’ordine in cui il resolver le consulta — quale profilo vince quando un client combacia con un device, un group e una subnet tutti insieme — vedi processo di filtraggio. Questa pagina è la struttura; quella è il runtime.