DHCP-DNS Di Giuseppe Latini

Transcript

1 DHCP-DNS Di Giuseppe Latini Prima di entrare nel vivo della configurazione dei demoni, spendiamo due parole per spiegare l utilità di questi due servizi di rete. DHCP vuol dire: Dynamic Host Configuration Protocol In pratica, una volta stabilite le regole, consente di configurare le interfacce di rete dei client di una certa sottorete in modo completamente automatico. I parametri che saranno configurati sono: Indirizzo IP, Maschera di sottorete, Default Gateway, DNS Server. DNS vuol dire: Domain Name Service E un servizio che, interrogato dai propri client, traduce in indirizzi IP e memorizza (per un tempo configurabile), i nomi che puntano agli HOSTS nei vari domini cercati, interrogando a sua volta i server root. Ha diverse modalità di funzionamento, a seconda se esiste o meno un dominio su cui si ha autorità, se esiste o meno un dominio di cui si è SLAVE cioè che viene cachato completamente. Cerchiamo di capire i vantaggi di avere un DNS server nelle immediate vicinanze dei client. Ogni volta che un client esegue la richiesta di un indirizzo IP al DNS a partire dal nome, genera ovviamente traffico in rete, se il DNS si trova nella stessa rete del client e ha già l informazione cercata nella sua CACHE, il client avrà la sua risposta in tempo molto breve, senza spreco della banda usata invece per la navigazione in internet. Inoltre, anche il provider di connettività ne trae beneficio, infatti il suo DNS sarà meno occupato e quindi anch esso più veloce nelle risposte. Per maggiori informazioni consultate

2 Caso Aziendale Supponiamo il caso di una WAN aziendale con più sedi, collegate a stella ad una centrale, ed anche ad un intranet di un ced per la fruizione d alcuni servizi, attraverso linea dedicata. Originariamente, il piano d indirizzamento dei vari hosts della WAN era statico, quindi ciascun client aveva un suo ben determinato indirizzo a partire dal nome host (per comodità corrispondente al nome netbios) a lui assegnato. Esempio: Rete CED: /8 Rete AZIENDA: /8 Rete AZIENDA SEDE n: 20.n.1.0/24 Problemi: 1) Alcuni host del CED ed anche dell AZIENDA, forniscono dei servizi, quindi i client per usufruirne, devono necessariamente conoscere gli indirizzi IP di questi servers. Nel caso in cui per esigenze organizzative, legate ad esempio a ristrutturazioni di lan, spostamenti di servers ecc. ecc., gli indirizzi dovessero cambiare, queste variazioni dovrebbero essere comunicate a tutti gli utenti, in modo da poter continuare ad utilizzare le applicazioni ed i servizi forniti. 2) Ogni qualvolta un client viene spostato da una sede all altra, va riconfigurato per lavorare correttamente in quella sottorete. Immaginiamo le difficoltà nel caso di un portatile.

3 SOLUZIONI La soluzione al primo problema è senza dubbio la configurazione di DNS, allestendo due domini, uno per il CED ed uno per l AZIENDA. Il server dell AZIENDA, sarà autorevole per il dominio azienda e slave per il dominio ced viceversa, il server del CED sarà autorevole per il dominio ced e slave per quello azienda in modo che anche dal ced sia possibile risolvere nomi relativi a indirizzi dell azienda, ad esempio per fornire assistenza! La soluzione al secondo problema, ovviamente è la configurazione di un server DHCP in grado di gestire le varie sottoreti, inoltre sarà necessario aggiungere all interfaccia di lan di ciascun router remoto, una route che indichi dove si trova il server DHCP per soddisfare le richieste dei clients (generalmente questo tipo d attività va fatta a carico del provider di connettività, ad es. Telecom Italia). In realtà, il DHCP aiuta anche nella soluzione del primo punto, infatti, è sufficiente dire al client usa dhcp per configurare automaticamente anche il corretto valore del DNS! Se consideriamo che esiste un tool Nwset.exe che consente di eseguire quest impostazione, in clients Windows, pure via rete... capiremo di poter eseguire l attribuzione di IP dinamico e DNS in modo molto semplice e veloce!

4 INSTALLAZIONE E CONFIGURAZIONE DHCP Per quanto riguarda l installazione, ovviamente i passi da seguire, cambiano a seconda della distribuzione utilizzata. Io ho usato una RED-HAT 7.3 (si può dire?) e quindi ho utilizzato il tool kpakage in ambiente X per installare il demone dhcpd la versione da me usata è la 2.0pl5.. dovrebbe essere l ultima stabile. Vediamo ora la configurazione, file /etc/dhcpd.conf : # # Sede principale # subnet netmask { range ; option routers ; option subnet-mask ; option domain-name "azienda"; option domain-name-servers ; default-lease-time ; max-lease-time ; } # # Sede 2 # subnet netmask { range ; option routers ; option subnet-mask ; option domain-name "azienda"; option domain-name-servers ; default-lease-time ; max-lease-time ; } Per far sì che il servizio sia avviato automaticamente all avvio del computer, nei percorsi: /etc/rc.d/rc3.d /etc/rc.d/rc5.d deve essere presente il seguente file (con permessi rwx): S35dhcpd symbolic link to:../init.d/dhcpd Volendo, è possibile stoppare e startare il demone manualmente, con i comandi: /etc/rc.d/init.d/dhcpd stop /etc/rc.d/init.d/dhcpd start /etc/rc.d/init.d/dhcpd restart /etc/rc.d/init.d/dhcpd reload

5 FUNZIONAMENTO DHCP Normalmente, quando un client viene configurato per usare il servizio dhcp, c è uno scambio di quattro pacchetti fra client e server, il primo è costituito da una richiesta all indirizzo di broadcast da parte del client: DHCPDISCOVER il client, dichiara il proprio MAC e cerca un server dhcp. il server DHCP, riceve questa richiesta, registra il MAC del client ed alla fine risponde con un: DHCPOFFER fornendo al client una licenza per usare un determinato indirizzo, valida per un certo tempo. A questo punto il client, spedisce un altro pacchetto: DHCPREQUEST richiedendo al server di poter usare, l indirizzo per cui gli è stata fornita la licenza al passo precedente. Se non ci sono problemi, il server risponde: DHCPACK ed il gioco è fatto! Il server, fornisce tutti gli elementi necessari alla configurazione dell interfaccia di rete del client e memorizza la fornitura di indirizzo appena effettuata, in /var/lib/dhcp/dhcpd.leases.

6 INSTALLAZIONE E CONFIGURAZIONE DNS La versione di Linux Red Hat 7.3, già in fase di installazione, consente di aggiungere il software necessario per implementare un DNS server: BIND (aggiornato poi alla 9.2.1) La configurazione, deve necessariamente essere eseguita a mano in base alle proprie esigenze. Ogni DNS server può essere sia Autorevole sia Slave per più zone. Il file centrale di configurazione è: /etc/named.conf... analizziamo un esempio: // generated by named-bootconf.pl options { directory "/var/named"; /* * If there is a firewall between you and nameservers you want * to talk to, you might need to uncomment the query-source * directive below. Previous versions of BIND always asked * questions using port 53, but BIND 8.1 uses an unprivileged * port by default. */ // query-source address * port 53; // forwarders { controls { inet allow { localhost; } keys { rndckey; zone "." IN { type hint; file "named.ca"; zone "azienda" IN { type master; file "azienda.zone"; allow-update { none; zone " in-addr.arpa" IN { type master; file "named.azienda"; allow-update { none; zone "ced" IN { type slave; masters { x.x.x.x; file "ced.zone"; include "/etc/rndc.key";

7 Nel paragrafo options osserviamo la clausola: directory / var/named ; serve ad impostare il percorso che dovrà ospitare gli altri file di configurazione delle varie zone, di seguito c è la clausola commentata // query-source address * port 53; Questa attivata nel caso in cui sullo stesso computer sia attivo un firewall. Scendendo ancora in basso, troviamo commentata // forwarders { all interno è possibile specificare indirizzi di altri dns a cui la richiesta del client potrebbe essere inoltrata. Il paragrafo controls serve per determinare quali hosts hanno privilegi amministrativi, in questo caso, localhost ovvero lo stesso elaboratore su cui gira il DNS. e gli host che sono muniti della giusta chiave. Osserviamo l ultima riga, contiene la clausola include / etc/rndc.key ; il file specificato, contiene informazioni circa l algoritmo e la chiave di cifratura usati per lo scambio di informazioni amministrative protette nel canale di controllo. Passiamo ora a descrivere i paragrafi relativi alle zone, troviamo la zona. O root che punta al file named.ca questo contiene i riferimenti necessari per raggiungere i root servers attivi. Periodicamente potrebbe rendersi necessario aggiornare tale file per aggiungere eventuali nuovi entrati. Quindi abbiamo la zona azienda di tipo master, nessun host è abilitato ad aggiornarla automaticamente allow-update {none; fa riferimento al file azienda.zone che riporto sotto:... $TTL $ORIGIN 1D IN root ( 1D IN 1D IN A www 1D IN A web 1D IN A corsi 1D IN A ftp 1D IN A ; serial (d. adams) 3H ; refresh 15M ; retry 1W ; expiry 1D ) ; minimum Le informazioni che troviamo all interno sono: $TTL (Time To Live o Tempo di Vita) espresso in secondi, rappresenta il tempo in cui le informazioni di questo dominio, replicate negli eventuali altri server, devono essere ricaricate dal server principale. $ORIGIN qui si scrive il nome del dominio. A seguire abbiamo il record SOA ovvero Start Of Autority, dove troviamo informazioni sui criteri di propagazione durante la replica della zona. Il valore delle colonne seguenti è partendo da sinistra: Nome macchina; tempo di validità; luogo (IN=Internet); tipo di record; indirizzo IP NB: nel caso di inserimento di record relativi allo stesso nome (esempio load balancing), il nome macchina può essere indicato anche solo sul primo record della serie.

8 Per attivare la risoluzione inversa ovvero trovare il nome a partire dall indirizzo, abbiamo definito un altra zona: in-addr.arpa che fa riferimento al file: named.azienda riportato di seguito: $TTL IN SOA azienda. root.azienda. ( ; Serial ; Refresh ; Retry ; Expire ) ; Minimum IN NS azienda. 1 PTR ftp.azienda. 2 PTR 3 PTR web.azienda. 4 PTR corsi.azienda.. Analizziamo in dettaglio anche questo file. Nel primo record abbiamo il solito $TTL impostato a secondi, ovvero 24h. A seguire c è il record SOA dove troviamo specificato il nome del dominio, l indirizzo di mail dell amministratore... tipicamente root.dominio e altre informazioni sui criteri di propagazione durante la replica della zona. Poi abbiamo il record NS (Name Server) dove solitamente si ripete il nome del dominio. A questo punto ci sono i record PTR (Pointer), uno per macchina... L indirizzo si ricava prendendo il nome della zona in-addr.arpa, togliendo la stringa inaddr.arpa, ribaltandolo (Cioè riscrivendolo da sinistra verso destra, leggendolo invece da destra verso sinistra) e aggiungendo il numero presente nella prima colonna del record PTR. Ad esempio nel primo record PTR abbiamo: ( invertito).1 (valore della prima colonna) = PS: Le zone possono contenere anche altri tipi record per descrivere funzionalità non trattate in questo testo. Le spiegazioni sulla sintassi dei tipi record specificati, si basano in parte su documentazione reperita in internet, in parte su dati sperimentali frutto di intuizioni, inoltre fanno riferimento alle release di software indicate all inizio di questo documento. Dimenticavo, Nei percorsi: /etc/rc.d/rc3.d /etc/rc.d/rc5.d deve essere presente il file (con permessi rwx): S45named symbolic link to:../init.d/named Non deve essere presente il file: K45named Per uso amministrativo e/o diagnostico, si possono dare svariati comandi da consolle, ne elenco solo alcuni: /etc/rc.d/init.d/named {start stop status restart condrestart reload probe}, inoltre dig = Domain Information Gropher Un supporto viene aggiunto dal comando rncd che consente una gestione remota. Per concludere, ovviamente come in tutte le licenze GNU... NO WARRANTY quindi.. se non riuscite a far funzionare i vostri DHCP e/o DNS.. non prendetevela con me ;) Spoleto, 21 nov. 02 Giuseppe Latini.