DHCP: scope, riservazioni e alta disponibilita

Il DHCP è il servizio in cui un dettaglio di configurazione diventa immediatamente «la rete non funziona». AZ-802 lo sa, e le domande di questo dominio raramente ti chiedono che cos’è uno scope: ti mettono davanti una configurazione che sembra corretta — servizio avviato, scope creato e attivato, IP statico — e ti chiedono perché nessun client ottiene un lease. La risposta sta quasi sempre in uno dei cinque punti che seguono.

Installare e autorizzare il ruolo

L’installazione è la parte breve: il server deve avere un IPv4 statico, e il ruolo si aggiunge con

Install-WindowsFeature DHCP -IncludeManagementTools

senza riavvio. La configurazione post-installazione crea i gruppi locali DHCP Administrators e DHCP Users e — in dominio — propone l’autorizzazione in Active Directory.

Ed è qui che sta il punto d’esame. Un server DHCP membro di un dominio AD DS che non è autorizzato non rilascia lease: il servizio parte, lo scope risulta attivo, ma il DHCP smette di servire i client. Non è un bug, è la protezione contro i rogue DHCP server. Il sintomo canonico è l’Event ID 1046 nel log System («it is not authorized to start. It has stopped servicing clients») e la freccia rossa verso il basso sul nodo IPv4 nella console.

Add-DhcpServerInDC -DnsName DHCP1.corp.contoso.com -IPAddress 10.0.0.3
Get-DhcpServerInDC

L’autorizzazione scrive un oggetto in CN=NetServices,CN=Services,CN=Configuration della foresta, via LDAP. Due conseguenze che l’esame sfrutta:

• serve un account con privilegi sufficienti — in pratica Enterprise Admins, perché si scrive nel contenitore Configuration della foresta, non nel dominio;
• il server rivalida la propria autorizzazione ogni ora. Se il suo indirizzo IP non compare più nell’elenco, si deautorizza da solo. Un’autorizzazione che «funziona e poi dopo qualche giorno smette» non è un problema di DHCP: qualcuno o qualcosa sta cancellando l’oggetto in AD.

Se l’autorizzazione fallisce con errore 20070 («The DHCP service could not contact Active Directory»), si controlla la raggiungibilità del DC sulla porta LDAP (Test-NetConnection -ComputerName 10.0.0.10 -Port 389) e, con adsiedit.msc, la presenza di oggetti in conflitto: voci il cui CN contiene il tag CNF: generate da problemi di replica. Finché quel conflitto esiste, il server non si autorizza.

Nota di perimetro: un server standalone in workgroup non si autorizza — il meccanismo di rogue detection vive solo in AD DS, e Add-DhcpServerInDC lì non va eseguito.

Scope: pool, esclusioni, riservazioni

Uno scope è un intervallo contiguo di indirizzi più subnet mask, durata del lease e opzioni. Regola di progetto: una subnet, uno scope, un solo range continuo. Se ti servono più intervalli utilizzabili dentro la stessa subnet, non crei due scope: crei uno scope che copre tutta la subnet e poi ritagli esclusioni.

Add-DhcpServerv4Scope -Name "Contoso network" -StartRange 10.20.0.1 -EndRange 10.20.0.254 -SubnetMask 255.255.255.0
Add-DhcpServerv4ExclusionRange -ScopeId 10.20.0.0 -StartRange 10.20.0.50 -EndRange 10.20.0.50
Add-DhcpServerv4Reservation -ScopeId 10.20.0.0 -IPAddress 10.20.0.100 -ClientId "00-11-22-33-44-55"
Set-DhcpServerv4OptionValue -ScopeId 10.20.0.0 -OptionId 6 -Value "10.20.0.10","10.20.0.11"

La distinzione fra i tre modi di «bloccare» un indirizzo è il cuore del punto Create IP reservations, e l’esame la chiede quasi sempre sotto forma di scenario misto:

Sbagliare verso costa: mettere una riservazione per un dispositivo che non fa DHCP non protegge nulla (nessuno la reclamerà, ma soprattutto l’indirizzo resta assegnabile solo perché riservato a un MAC che non chiede mai — e un’appliance statica dentro il pool produce conflitti e voci BAD_ADDRESS fra i lease). Mettere un’esclusione su una stampante che fa DHCP significa lasciarla senza indirizzo.

Le opzioni seguono una precedenza che va sapere a memoria: server < scope < class/policy < riservazione. L’opzione più specifica vince, e quella impostata sulla riservazione batte tutto il resto.

Più subnet sullo stesso cavo, e subnet senza server

Due scenari diversi che l’esame ama accostare.

Stesso segmento fisico, seconda subnet logica (multinet). Il pool di 172.16.10.0/24 è esaurito, la rete aggiunge 172.16.11.0/24 sullo stesso segmento e mette entrambi gli indirizzi sull’interfaccia del router. Sul DHCP si crea il secondo scope e poi si raggruppano i due scope in un superscope: è l’unico costrutto che consente a un server di servire più subnet sullo stesso segmento fisico. Senza superscope il server, che si lega alla subnet della propria interfaccia, non offre indirizzi del secondo range ai client che arrivano in broadcast da quel segmento.

Segmento remoto senza server. I client mandano DHCPDISCOVER in broadcast, e i router per default non li inoltrano. Le due soluzioni sono: configurare il relay sul router (ip helper-address 10.0.1.1), oppure — quando il router è di terze parti e la rete non lo tocca — mettere nella subnet remota un Windows Server con il DHCP Relay Agent. Attenzione: il relay agent non fa parte del ruolo DHCP. Si installa il ruolo Remote Access con il role service Routing, si configura LAN routing in Routing and Remote Access, si aggiunge DHCP Relay Agent come nuovo protocollo di routing sotto IPv4, gli si assegna l’interfaccia e si indica l’IP del server DHCP. Sul DHCP deve comunque esistere uno scope attivo per la subnet remota.

Alta disponibilità: failover, non «due scope uguali»

L’errore classico — e una domanda del banco è costruita esattamente su questo — è mettere due server autorizzati, ciascuno con uno scope attivo che copre lo stesso range completo della stessa subnet. Non è ridondanza: è una fabbrica di indirizzi duplicati, perché i due server non si parlano e non sanno che cosa ha già assegnato l’altro.

Il failover replica scope e lease attivi fra esattamente due server, è solo IPv4, usa TCP 647 e pretende che l’orologio dei due partner non differisca di più di un minuto (oltre, il wizard si ferma con errore). Il MCLT (maximum client lead time) è la durata del lease temporaneo che un partner concede quando ha perso contatto con l’altro, prima di potersi assumere l’intero pool. Due dettagli operativi che cadono spesso: le modifiche a uno scope in failover non si propagano da sole (vanno replicate a mano, e la replica sovrascrive il partner: si lancia sempre dal server che ha la configurazione buona), e se i server aggiornano il DNS per conto dei client devono usare le stesse credenziali di dynamic update, altrimenti il secondo server non riesce a modificare record di cui il primo è proprietario. Infine, se i client sono dietro a un relay, servono due helper-address: devono poter raggiungere entrambi i partner.

Troubleshooting dell’indirizzamento, anche ibrido

La checklist ufficiale, nell’ordine in cui conviene percorrerla: servizio avviato; server autorizzato; indirizzi ancora disponibili nello scope; presenza di BAD_ADDRESS fra i lease (segnale di IP statici non esclusi); binding del server su un IP che appartiene alla subnet dello scope, verificabile con Get-DhcpServerv4Binding; nessun altro processo in ascolto su UDP 67/68 (tipicamente WDS/PXE), controllabile con netstat -anb; raggiungibilità del relay agent; policy e filtri MAC configurati. Un client con indirizzo 169.254.x.x (APIPA) non ha ricevuto risposta: il problema è a monte, non sul client. I log di debug stanno in %windir%\System32\Dhcp.

Capitolo a parte: la registrazione DNS fatta dal DHCP. Gli eventi 20317-20327 raccontano esattamente quale registrazione è fallita. Il caso più citato è l’ID 20319 — DHCPv4.PTRRecordDNSFailure: i record A dei client compaiono regolarmente nella zona diretta, ma il PTR fallisce. La causa quasi sempre è che manca la zona di reverse lookup per quella subnet (o è configurata male). Si crea la reverse lookup zone corrispondente e gli errori cessano; non c’è nulla da sistemare sullo scope.

Sul versante ibrido valgono regole diverse, perché in una VNet Azure il DHCP lo fornisce la piattaforma: la VNet non è un dominio di broadcast, broadcast e multicast non sono supportati, e l’indirizzo privato di una VM si fissa dal NIC in Azure, mai configurandolo staticamente dentro il guest OS. Puoi ospitare un server DHCP Windows su una VM Azure, ma per servire client on-premises attraverso un relay agent. C’è una trappola precisa: il rinnovo unicast diretto del client on-prem verso il server in Azure (UDP/68 → UDP/67) non è supportato e va in timeout a T1; il rinnovo riesce a T2, quando il client passa dal relay agent. Infine, se cambi l’elenco dei DNS server della VNet, le VM prendono le nuove impostazioni solo dopo un rinnovo del lease (ipconfig /renew).

Trappole tipiche d’esame

• Scope attivo + servizio avviato + IP statico, e nessun lease: in dominio la risposta è autorizzazione in AD, non «ricrea lo scope» o «riavvia il servizio». Cerca l’Event ID 1046. E ricorda che l’autorizzazione si rivalida ogni ora: può sparire dopo giorni.
• Esclusione contro riservazione: se il dispositivo ha un IP statico e non parla mai col DHCP serve un’esclusione; se prende l’indirizzo via DHCP ma deve riceverne sempre lo stesso serve una riservazione. Una stessa domanda mette entrambi i casi nella stessa subnet, e vuole due azioni diverse.
• Seconda subnet logica sullo stesso segmento fisico: la risposta è superscope, non «allarga il range» (i range di uno scope devono essere contigui e coerenti con la maschera) e non «aggiungi un secondo server».
• Due server con lo stesso range completo e attivo non sono alta disponibilità: servono un failover relationship (load balance o hot standby) oppure pool disgiunti via esclusioni. E il failover è solo IPv4, massimo due server, con orologi allineati entro un minuto.
• A sì, PTR no: l’evento 20319 punta alla reverse lookup zone mancante, non alle credenziali di dynamic update né allo scope. Le credenziali condivise sono invece il tema quando i due partner di un failover si contendono la proprietà dei record.
• Il DHCP Relay Agent non è nel ruolo DHCP: si installa con Remote Access / Routing. Se lo scenario dice che il router di terze parti non verrà toccato, la risposta è un relay agent Windows nella subnet remota — non «sposta il server».
• In Azure non si «installa il DHCP per la VNet»: l’indirizzamento delle VM è della piattaforma e l’IP privato fisso si imposta sul NIC. Un DHCP in VM Azure serve i client on-premises, tramite relay.