Processo di filtraggio

La configurazione di Warden ha sette sostantivi: blocklist, admin rules, profili, device, gruppi, subnet, schedule. Una volta che vedi come si referenziano e in che ordine il resolver li consulta, il resto della documentazione diventa una variazione su un unico tema. Questa pagina è quel tema.

Come una query viene risolta

Per ogni query, Warden esegue una sola cascata in due fasi: prima sceglie il profilo (prima scala), poi chiede a quel profilo cosa fare con il dominio (seconda scala).

La prima fase — quale profilo si applica? — percorre cinque livelli in ordine fisso. Vince il primo livello che combacia. La seconda fase — cosa dice quel profilo su questo dominio? — percorre i layer di regole all’interno del profilo scelto.

Alcune cose che queste scale inchiodano e che la prosa da sola tende a glissare.

Lo schedule vince sul profilo diretto del device, non viceversa. La numerazione qui sopra non è casuale: lo schedule è L2 e la riga diretta del device è L1, ma il resolver controlla prima L2. Il ragionamento è l’intuizione dell’operatore — se scrivi uno schedule per un device che ha già un profilo diretto, vuoi chiaramente che lo schedule vinca durante la sua finestra, altrimenti non avrebbe alcun effetto.

Gli schedule scattano solo se il client ha matchato una riga device. Uno schedule è agganciato a un id di device (o a un id di gruppo, indirettamente via device.groups). Un client risolto a L4 (subnet) o L5 (default) non può attivare uno schedule, neanche se il profilo overlay coincide con quello su cui finisce. Se ti serve un comportamento temporizzato per un client “senza riga device”, modellalo con subnet separate o con i futuri schedule per-regola — non con [[schedules]].

I gruppi non accettano IP grezzi. Una riga [[groups]] referenzia solo id di device. Un client senza riga device non può mai raggiungere L3, punto. È per questo che “blocca la VLAN dei bambini alle 20” si esprime di solito come subnet kids-VLAN → profilo kids-strict, non come gruppo con schedule.

Prefisso più lungo, non primo dichiarato. Quando due [[subnets]] si sovrappongono, vince il CIDR più specifico, indipendentemente dall’ordine nel file. Il campo opzionale priority sulle subnet è informativo; il motore usa il longest-prefix.

override_profile_deny copre una cella stretta. Una regola allow a livello device può tranquillamente consentire domini che il profilo bloccherebbe via blocklist — nessun override necessario. Il flag override serve solo quando una device.allow entra in conflitto con una admin rule deny a livello profilo sullo stesso dominio. Il validator rifiuta quella combinazione in fase di scrittura se non è presente override_profile_deny = true.

Strict-by-default

Se nessun livello matcha e default_profile non è impostato, la risposta è REFUSED — mai un default permissivo.

Prima di SN3 c’era un flag dedicato server.block_unmapped_clients che rendeva la cosa esplicita. SN3 ha ritirato il flag perché lo stesso effetto cade naturalmente fuori dalla cascata: lascia default_profile non impostato e qualsiasi client che non matcha device, gruppo o subnet cade a L5 e viene rifiutato. Il RCODE=REFUSED a L5 è hardcoded — ignora il block_response di qualsiasi profilo, così un profilo permissivo non può diventare per sbaglio la modalità open-resolver della rete.

Imposta default_profile solo quando vuoi davvero una policy catch-all (per esempio ogni ospite riceve il profilo “ads-blocked”). Lasciarlo non impostato è la postura strict-allowlist.

Il cast

I profili sono il centro. Tutto il resto o punta a un profilo, o è referenziato da un profilo.

Un profilo è un bundle di policy: a quali blocklist ti abboni, quali admin rule colleghi, cosa rispondere quando una query viene bloccata. Device, gruppi e subnet sono tre modi diversi di dire “questo client riceve quel profilo”. Gli schedule sono un override temporizzato che sostituisce un profilo durante una finestra di tempo. Blocklist e admin rule sono la materia prima da cui i profili sono composti.

Alcuni fatti di cardinalità che la tabella non urla:

• Un device punta a un solo profilo (opzionale). Può appartenere a molti gruppi.
• Un gruppo ha un profilo e molti device.
• Una subnet ha un profilo e molti CIDR.
• Una blocklist o una admin rule è referenziata da molti profili.
• Uno schedule ha esattamente un target (un device o un gruppo, mai entrambi) e un profilo overlay.

La separazione tra identità (devices, groups, subnets) e policy (profiles, blocklists, admin_rules) è deliberata. Le entità identità non portano mai regole inline — puntano solo a un profilo. È per questo che lo stesso profilo può governare il tuo portatile, i tablet dei bambini e la VLAN ospiti senza tre copie duplicate dello stesso ruleset.

Dove è documentata ciascuna entità

Questa pagina è la mappa. Il territorio sta a un click di distanza.

• Profili — il bundle di policy a cui ogni altra entità punta: vedi Profili.
• Device, Gruppi, Subnet — i tre layer di identità che alimentano L1 / L3 / L4: vedi Device, Gruppi, Subnet.
• Admin rule — le regole tipizzate allow/deny/regex referenziate da profili e (per id) da device: vedi Admin rules.
• Schedule — overlay di profilo temporizzati per device e gruppi matchati: vedi Schedule.
• Blocklist — feed esterni di domini sottoscritti dai profili: vedi Blocklist.
• Lo schema TOML completo — ogni campo, ogni default, ogni vincolo: vedi lo Schema TOML di Warden.