Configurazione automatica degli host in rete: DHCP

Transcript

1 Laboratorio di Amministrazione di Sistemi A.A. 2006/2007 Configurazione automatica degli host in rete: DHCP Dal materiale originale di Luca Ghedini Facoltà di Ingegneria Boot me Boot me Ogni elaboratore ha bisogno di un set di informazioni per lavorare (in rete). Pochi elaboratori e nessuna mobilità -> può procedere manualmente. Molti elaboratori (mobili) -> il caos:

2 Cosa occorre per partire Al minimo un indirizzo ip e una netmask ma anche : 1 default gateway 1 dns 1 server da cui caricare il stema operativo etc Primo tentativo: RARP Protocollo di livello 2 Stesso formato di pacchetto di ARP Differente layer 2 protocol type Multi server

3 RARP Server 1 Client Server 2 Req Reverse Req Reverse Rep Reverse Rep Reverse Rarp: difetti Pensato per ottenere solo 1 indirizzo IP layer 2 -> forte dipendenza dallo HW/kernel Nessuna negoziazione fra Client/Server Multi server ma nessun coordinamento fra i server Funzionamento solo entro un dominio di broadcast

4 BOOTP Protocollo di livello 3 (IP) Meccanismi di negoziazione Client/Server Meccanismi di assegnamento temporaneo di IP Multi server Posbilità di poter far arrivare al client TUTTE le informazioni necessarie per il funzionamento Integrazione con altri protocolli (TFTP) per boot remoto BOOTP: highlights 2 soli tipi di messaggi : BOOPREQUEST,BOOTREPLY Il server ascolta sulla porta 67 Il client ascolta sulla porta 68 1 solo tipo di pacchetto Funzionamento in più domini di broadcast

5 sec from init boot 1:bootreq 2:bootreply Pacchetto BOOTP Hw type (ethernet=1) Hw addr len (ethernet=6) Transaction ID op htype hlen hops xid secs flags ciaddr yiaddr addr giaddr chaddr (16) sname (64) file (128) options (64) B NBZ Client IP addr Your IP addr Server IP addr Client HW addr Preferred Server name File to boot Specific options secondi passati dall inizio del boot op=1 secs xid ciaddr yiaddr addr giaddr chaddr sname file options flags BOOTREQ Numero casuale per permettere al client di riconoscere la risposta del server Hw Client in grado di accettare unicast PRIMA del boot? B=0 no B=1 Client conosce il suo (dedera un) IP? ciaddr=ip, B=0 no ciaddr= Client MAC addr Client ha preferenze di server? same=server Name no sname=

6 BOOTREQ: campo file Identificativo per indicare al server che tipo di client è (es:sun oppure linux) Nulla ( ): client standard /non interessato al boot remoto ma solo a parametri. sname=? sono io? BOOTREP (1 dom bcast) ciaddr=0? può usarlo? ho IP libero? yaddr=ip fname=? end ho il file? fname e options B=0? invia risposta broadcast invia risposta al client

7 In the large Al crescere del numero di host occorre creare sottoreti bootp basa su brodcast: funzionamento solo entro lo stesso dominio di broacast Posbili soluzioni : Un server per ogni sottorete Un server unico e uso di proxy-agent (bootp relay agent) BOOTP Relay Agent Si comporta come un proxy. NON comporta come un router IP Accetta richieste da client in una sottorete ed emette richieste in altre sottoreti Propaga all indietro le risposte Usualmente è integrato dentro router Usa i campi giaddr e hop del pacchetto bootp

8 relay (esempio) client giaddr 0 relay kh relay a b server server hop 0 giaddr a giaddr k hop 1 hop 1 giaddr k hop 2 net 1 net 2 net 3 Relay Agent (RA): note RA Può usare il campo sec come 1 fattore per decidere sul relay RA Ignora i BOOTPREQ con hop > soglia (max16) RA Incrementa sempre hop ad ogni forward RA Modifica giaddr solo se e vuoto Come (uni,multi,broad) e a chi fare il relay è una scelta dell amministratore di rete RA deve usare lo stesso ineme di destinatari per ogni determinato client RA fa il relay di pacchetti BOOTREPLY solo a client e non ad altri RA

9 sname=? sono io? BOOTREP (+ dom bcast) ciaddr=0? può usarlo? sul mio dom di bcast? ho IP libero? yaddr=ip fname=? end ho il file? fname e options invia al RA invia al RA giaddr=0? B=0? invia risposta broadcast invia risposta al client BOOTPREPLY: riassunto BOOTPREQ field ciaddr giaddr B BOOTREPLY value dst port dst ip dst l X X bootpc(68) ciaddr std (arp) X bootps(67) ciaddr std (arp) bootpc(68) yiaddr chaddr bootpc(68) ff.ff.ff.ff broadcast

10 BOOTREQ: campo options Usato anche dopo la fase di boot I primi 4 byte = (hex - magic cookie) Serie libera di campi tagged (tag, len, value): Di lunghezza fissa Di lunghezza variabile Fixed Len Subfield tag/len 0/0 nome pad gnificato Usato per allineare i dati 1/4 subnet mask netmask 2/4 255/0 time offset from UTC end differenza fra l ora locale e l ora UTC fine campo opzioni

11 tag nome Var Len Subfield gnificato gateways time servers name serves domain name reserved specific local IP gateways IP time servers IP of Name Servers domain name (riservati: gestiti dai IANA) Ad uso locale Ancora non basta Al crescere della compestà sempre più informazioni sono necessarie per inizializzare le macchine IP come risorsa: mancano meccanismi per restituirli (dopo la acquizione) Nascita di DHCP (Dynamic Host Configuration Protocol) come protocollo trasportato dentro i pacchetti bootp (nel campo option)

12 DHCP highlights Compatibile con i client ed i relay agent bootp IP dati a client per durate di tempo limitate Posbilità per i client di chiedere proroghe della scadenza Posbilità per i client di disdire l uso dello IP Stesso formato di pacchetto di bootp (ma campo option di lunghezza variabile) I messaggi da client server imbustati dentro bootreq I messaggi da server client imbustati dentro bootreply DHCP discover offer request ack nack decline release inform DHCP:Messaggi Client bcast to locate server Server offer parameter to client Client request parameter offer by 1 server Server to Client: commit Server to Client: not commit Client to Server: ip already in use Client to Server: release ip Client to Server: ask for other things

13 server (non scelto) DHCP:Esempio client discover server (scelto) offer offer request ack release server (non scelto) DHCP:Esempio di riuso client server (scelto) request ack ack release

14 Sul riuso Il client informa i sever che intende usare un ip (specificato con una option) I server che hanno conoscenza dei parametri usati dal client asssentiscono SENZA alcuna verifica che IP a libero (es ping): il client potrebbe già usarlo I server possono negare il riuso (nack): es client ha cambiato sottorete Se il client scopre IP occupato: decline Altre informazioni Se il client dedera altre informazioni: inform Il server risponde con un ack contenente le informazioni server (non scelto) client server (scelto) inform ack ack

15 Altre opzioni tag nome host name name serves req ip lease time DCHP msg server id max msg len client id gnificato client host name IP of Name Servers in discover a client ask for IP use by server/client (in sec) type of message max len client can accept tag nome lpr server host name name servers vendor class smtp server pop server gnificato printer servers client host name IP of Name Servers Client hw type servers pop servers

16 Problemi aperti Client e server devono avere orologi che NON scorrono l uno rispetto all altro. Il protocollo è del tutto incuro! Posbilità di denial of service Difficoltà di load balancing inconstenza fra i servers curezza Cifrare tutto il traffico (es con RSA) computazionalmente troppo costo e incompatibile con attuale protocollo Aggiunta di una opzione (tag=90) che contiene il necessario per l autenticazione reciproca client/server e dei ngoli messaggi

17 PXE DCHP non risolve tutti i problemi: Può essere necessario fare domande all utente (es quale stema operativo, farlo autenticare, ecc): Preboot excution Eviroment Boot con un programma (bpbatch) in grado di interagire con l utente e poi fare il boot vero e proprio. Uso di dhcp/tftp per eseguire il tutto. Es le macchine del Lab! RFC