Perché un server DHCP necessita di un indirizzo IP statico?

Sto sperimentando varie configurazioni di rete utilizzando macchine virtuali. Quando installo il ruolo DHCP su Windows Server, richiede un IP statico. Ho difficoltà a capire perché questo è necessario da un punto di vista tecnico .

La mia comprensione del DHCP è che un client trasmette una richiesta di individuazione DHCP sulla rete e qualsiasi dispositivo sulla rete può rispondere. Un server DHCP ha quindi bisogno di un indirizzo IP, ma perché questo IP deve essere statico? Il server DHCP può ottenere il suo indirizzo altrove e comunque rispondere alla trasmissione purché abbia un IP.

Per esempio

• Server A , Server B e Client X sono tutti collegati allo stesso switch
• Il server A è 10.0.0.1 e serve 10.0.0.X / 24
• Il server A è configurato per fornire IP solo al server B tramite filtro MAC
• Il server B ottiene il suo IP dal server A , quindi vive su 10.0.0.X / 24
• Il server B serve 10.0.1.X / 24
• Il client X si connette e ottiene un IP dal server B

Naturalmente, una volta che il client X ottiene l'IP dal server B , non sarà in grado di contattare direttamente il server B poiché vivono su sottoreti diverse. Ma questo non è un problema: la richiesta DHCP è (inizialmente) una trasmissione, quindi tutti sullo switch la riceveranno.

Ignora un punto di vista gestionale, perché non posso averlo

• Un server DHCP master con IP statico, serve solo altri server DHCP
• Un intervallo di indirizzi per i server DHCP "secondari"
• Un intervallo di indirizzi per i client, ottenuto dai server DHCP "secondari"

C'è un motivo tecnico per cui i server DHCP devono avere un IP statico?

La mia comprensione del DHCP è che un client trasmette una richiesta di individuazione DHCP sulla rete e qualsiasi dispositivo sulla rete può rispondere.

Un client può anche effettuare una richiesta DHCP unicast, la richiesta di rinnovo viene effettuata in unicast, quindi il client richiede direttamente il server DHCP. Cosa succede se il DHCP cambia il suo indirizzo IP originale? Il rinnovo fallirà e la successiva richiesta verrà effettuata in trasmissione. Che non è un comportamento che ottimizzerà il tuo traffico di rete.

Microsoft:

Rinnovo di un lease Il client DHCP tenta innanzitutto di rinnovare il lease quando è trascorso il 50 percento del tempo di leasing originale, noto come T1. A questo punto il client DHCP invia un messaggio DHCPRequest unicast al server DHCP che ha originariamente concesso il suo contratto di locazione. Se il server è disponibile e il contratto di locazione è ancora disponibile, il server risponde con un messaggio DHCPAck unicast e il contratto di locazione viene rinnovato.

fonte

È C:

Internet Systems Consortium DHCP Client 4.2.2
Copyright 2004-2011 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth0/00:0c:29:ac:18:75
Sending on   LPF/eth0/00:0c:29:ac:18:75
Sending on   Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7 << First request
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPOFFER from 10.0.0.253
DHCPACK from 10.0.0.253
bound to 10.0.0.6 -- renewal in 133 seconds.



DHCPREQUEST on eth0 to 10.0.0.253 port 67 << Renewal
DHCPACK from 10.0.0.253
bound to 10.0.0.6 -- renewal in 119 seconds.
DHCPREQUEST on eth0 to 10.0.0.253 port 67
DHCPACK from 10.0.0.253
bound to 10.0.0.6 -- renewal in 118 seconds.

Una volta concesso il contratto di locazione, tuttavia, i futuri messaggi DHCPREQUEST / RENEWAL DHCP vengono unicast direttamente sul server DHCP

fonte

Un server DHCP deve avere un indirizzo IP configurato in modo che possa sapere quali ambiti sono collegati localmente alle interfacce fisiche e quali ambiti possono essere serviti solo tramite un relè DHCP.

Ignora un punto di vista gestionale,

Mi dispiace, ma penso che sia sciocco provare a sventolare la mano e ignorare i problemi pratici relativi alla gestione della rete. Ottenere un indirizzo IP valido è fondamentale sulla maggior parte delle reti. Non vorresti mai che il tuo server DHCP fallisse perché non poteva ottenere il suo indirizzo valido. Software e protocolli sono progettati per funzionare in situazioni pratiche comuni. Ciò che stai descrivendo sembra creare più luoghi in cui le cose falliscono con poco o nessun guadagno reale .

Se vuoi davvero avere un qualche tipo di configurazione dinamica di un server DHCP, probabilmente dovresti cercare di utilizzare un sistema di gestione della configurazione per applicare le impostazioni sul server DHCP, invece di provare a usare DHCP per configurare il tuo server DHCP.

Tecnicamente il server DHCP deve disporre di un indirizzo IP noto per i pacchetti inviati dopo il pacchetto di rilevamento iniziale. Questo indirizzo di solito deve essere conosciuto all'avvio, quindi è praticamente statico. Non deve (IIRC) trovarsi sulla stessa sottorete in modo che il relè DHCP funzioni, ma non funzionerà senza una route verso la sottorete su cui si sta allocando.

Se vuoi davvero farlo, puoi probabilmente organizzare qualcosa usando un'interfaccia virtuale in modo che l'adattatore fisico (server B) abbia indirizzi IP su entrambe le sottoreti che si trovano sul tuo filo (un DHCP e l'altro statico).

Come Zoredache, suggerirei che dovresti davvero attenerti a una configurazione del server DHCP per il filo. La maggior parte dei server DHCP consente di classificare i dispositivi in ​​vari modi (ad esempio: parti dell'indirizzo MAC) e di assegnarli a diverse sezioni della sottorete. Saresti quindi in grado di fornire regole firewall diverse a queste sottosezioni.

Non ci sarebbe differenza nella sicurezza perché qualsiasi client può impostare il proprio indirizzo statico in entrambi gli scenari.