3 155
contributi
Un server DNS e DHCP su Debian: differenze tra le versioni
Un server DNS e DHCP su Debian (visualizza wikitesto)
Versione delle 10:32, 12 feb 2012
, 12 feb 2012→Alcune note generali
Wtf (discussione | contributi) |
Wtf (discussione | contributi) |
||
| Riga 318: | Riga 318: | ||
* '''Dichiarazioni''': forniscono informazioni sulla topologia della rete, descrivono client e subnet, permettono di raggruppare parametri o altre dichiarazioni. | * '''Dichiarazioni''': forniscono informazioni sulla topologia della rete, descrivono client e subnet, permettono di raggruppare parametri o altre dichiarazioni. | ||
Nel caso di parametri d'avvio (boot parameters) definiti più volte, ma all'interno di differenti dichiarazioni, per determinare quali di questi un client deve adottare vale il principio di maggior specificità; per esempio un parametro presente all'interno della dichiarazione host prevale su qualsiasi parametro definito altrove: class, pool, subnet, shared-network.<br> | Nel caso di parametri d'avvio (boot parameters) definiti più volte, ma all'interno di differenti dichiarazioni, per determinare quali di questi un client deve adottare vale il principio di maggior specificità; per esempio un parametro presente all'interno della dichiarazione host prevale su qualsiasi parametro definito altrove: class, pool, subnet, shared-network.<br> | ||
Segue una breve descrizione di alcune dichiarazioni disponibili:* '''host''', contiene parametri e dichiarazioni relative ad uno specifico dispositivo fisico. Perché questo sia identificato univocamente è necessario dare un nome unico alla dichiarazione ''host'' e definire al suo interno il parametro ''hardware''. Si noti che il nome dato ad una dichiarazione ''host'' è del tutto arbitrario poiché completamente slegato dall'hostname del dispositivo fisico cui si fa riferimento; in caso di aggiornamento dinamico dei record DNS è possibile sostituire all'hostname del dispositivo uno di propria scelta attraverso il parametro ''ddns-hostname''. Dispositivi privi di una dichiarazione host vengono classificati come sconosciuti, cioè ''unknown-clients''.* '''class''', permette di attribuire uno stesso set di parametri e o dichiarazioni a più dispositivi che non siano definiti dalla direttiva ''host''.* '''pool''', associa set di parametri e/o dichiarazioni a specifici gruppi di indirizzi dinamici. Ogni dichiarazione ''pool'' deve contenere almeno uno di questi gruppi di indirizzi specificati attraverso la direttiva ''range'' ed è possibile regolarne l'accesso da parte dei vari client attraverso i parametri ''allow'', ''deny'' e ''ignore''. Ogni ''pool'' deve necessariamente essere inserita dopo le dichiarazioni ''subnet'' cui fa riferimento attraverso la definizione di ''range'', o al limite all'interno delle stesse (prestare attenzione alle pool che contengono intervalli di indirizzi appartenenti a più subnet).* '''subnet''', dichiarazione obbligatoria per ogni subnet che il server dhcp dovrà gestire. Eventuali parametri e dichiarazioni di valità generale, purché strettamente legati alla subnet, possono essere inclusi nella specifica dichiarazione ''subnet''. Si noti che i parametri ''allow'', ''deny'' e ''ignore'' se definiti all'interno di questa dichiarazione prevalgono su quelli omonimi eventualmente specificati all'interno delle dichiarazioni ''pool''. L'assegnazione di un client ad una certa subnet avviene esclusivamente sulla base dell'indirizzo IP associato al medesimo.* '''shared-network''', | |||
==== | ==== Allow e Deny known/unknown clients ==== | ||
È possibile visualizzare i dettagli dei dati ricevuti dal server dhcp leggendo | È importante prestare molta attenzione al parametro '''deny''' ''known/unknown clients'', infatti quando viene dichiarato in un certo ambito seguirà necessariamente che tutti gli ambiti più specifici ne saranno influenzati. Supponiamo per esempio di avere diversi intervalli di indirizzi IP e che la maggior parte di essi non debbano essere accessibili ai dispositivi sconosciuti; si potrebbe allora essere tentati di piazzare un bel ''deny unknown-clients'' a livello di ''shared-network'' o ''subnet'' e poi di dichiare ''allow unknown-clients'' nei singoli intervalli. Grave errore.<br>Quando un client contatta il server dhcp questi cerca un indirizzo IP e inizializza i vari parametri da passare al client; il server cerca una dichiarazione 'host'' per il client e non trovandola lo classifica come sconosciuto; successivamente valuta le dichiarazioni ''class'' (che supponiamo assenti) e poi quelle di tipo ''pool'', dove risulta che per tutte è possibile l'accesso da parte di client sconosciuti, poiché se non viene dichiarato ne ''allow' ne ''deny'' chiunque ha accesso al range di indirizzi in oggetto.<br>Il passo successivo è valutare le dichiarazioni ''subnet'' e ''shared-network'', dove per ipotesi il server troverà sicuramente la dichiarazione ''deny unknown-hosts''; poiché tale parametro non è mai stato definito in precedenza segue immediatamente che ''subnet'' o ''shared-network'' sono gli ambiti di definizione più specifici per il parametro, quindi quelli dove viene determinato il valore di ''deny'' per quanto riguarda l'accesso ai range di indirizzi (''allow'' e ''deny'' possono essere contemporaneamente usati anche per valutare altri aspetti).<br>Ricapitolando si ha che per la maggiranza delle dichiarazioni ''pool'' risulta definito il solo parametro ''deny unknown-clients'' come effettivamente desiderato, mentre per le rimanenti risultano definiti contemporaneamente ''deny unknown-clients'' e ''allow unknown-clients''. Come esplicitamente scritto nel manuale, qualora per un range di IP risultino definiti sia i parametri ''allow'' che ''deny'' il client può averne accesso solo se appartiene alla lista dei client permessi e contemporaneamente NON appartiene a quella dei client impediti. Risulta quindi evidente che avendo scelto di discriminare l'accesso sulla base di conosciuto/sconosciuto tutti i client sconosciuti si vedranno impedito l'accesso ad ogni ''pool'', poiché al più soddisfano la condizione ''allow'', ma non quella ''deny''.<br>L'unica soluzione, a meno di non optare per una valutazione basata sull'utilizzo delle classi invece della parola chiave conosciuto/sconosciuto, è quella di definire il solo parametro ''deny unknown-clients'' nelle ''pool'' dove si vuole negare l'accesso ai client sconosciuti. | ||
==== Conoscere i dettagli del ''lease'' concesso da client ==== | |||
È possibile visualizzare i dettagli dei dati ricevuti dal server dhcp leggendo i file contenuti in <code>/var/lib/dhcp/</code>. | |||
== Configurazione del DNS Dinamico == | == Configurazione del DNS Dinamico == | ||