Windows Server 2025 / Come risolvere problemi di IP, DNS e DHCP

Per diagnosticare la rete in Windows Server 2025, verifica separatamente configurazione IP, percorso di rete, risoluzione dei nomi DNS e servizio da utilizzare. Annota i valori attuali di CLIENT1, confronta lo stesso test con un client funzionante nella medesima rete e modifica una sola causa probabile prima di riprovare. Una risposta ping, una risposta DNS e una connessione a una porta dimostrano aspetti diversi.

Definisci il problema e le modifiche recenti

Delimita il problema: riguarda tutti i client o uno solo? Falliscono sia i nomi sia gli indirizzi, oppure soltanto i nomi? Non funziona un servizio specifico? Annota destinazione, ora, errore, riavvii recenti e modifiche ad adattatori, switch virtuali o opzioni DHCP. IP significa Internet Protocol, DNS è il sistema dei nomi di dominio (Domain Name System) e DHCP è il protocollo di configurazione dinamica degli host (Dynamic Host Configuration Protocol). Confronta client dello stesso segmento usando la medesima prova; cambiare insieme DNS e firewall impedisce di individuare la correzione efficace.

L’accesso tramite IP può aiutare a isolare un problema di nomi, ma non equivale sempre all’accesso tramite il nome del servizio. Possono cambiare i requisiti dei certificati e del protocollo di autenticazione Kerberos. Per impostazione predefinita Windows non tenta Kerberos se la destinazione è indicata come IP, come spiega la documentazione di Kerberos per destinazioni IP. Non trasformare una prova diagnostica in una modalità di accesso permanente senza verificarla e non ignorare gli avvisi sui certificati.

Leggi la configurazione effettiva del client

ipconfig /all
Get-NetIPConfiguration
Get-NetAdapter
Get-NetRoute -AddressFamily IPv4

Esegui questo blocco in Windows PowerShell dalla console di CLIENT1. Individua l’adattatore del laboratorio e annota IP, maschera, DNS, server DHCP, suffisso e modalità automatica o manuale. Dopo la configurazione DHCP, il laboratorio prevede 172.24.50.100–172.24.50.150, maschera 255.255.255.0 e DNS 172.24.50.10. Get-NetAdapter aiuta a controllare adattatore e stato; Get-NetRoute mostra prefissi e hop successivi, inclusa 0.0.0.0/0 se esiste una route predefinita. Una rete isolata senza router può comunicare nella propria subnet senza gateway; l’assenza di accesso a Internet è coerente con quel progetto. Se un’interfaccia non appare in Get-NetIPConfiguration, verifica -All o seleziona il suo indice effettivo secondo la guida alla lettura della configurazione IP.

Un indirizzo 169.254.x.x suggerisce che il client non abbia ottenuto un lease utilizzabile, ma non prova da solo un guasto al server DHCP. Controlla prima che la macchina virtuale sia accesa, l’adattatore abilitato e collegato allo switch corretto e, quando previsto, l’acquisizione IP automatica. Confronta anche il server DHCP effettivo con DC1. La guida ai problemi del client DHCP indica i registri Operational e Admin degli eventi del client DHCP nel Visualizzatore eventi, sotto Registri applicazioni e servizi. Cerca eventi riferiti all’ora e all’adattatore interessati.

Separa raggiungibilità e accesso al servizio

ping 172.24.50.10
Test-NetConnection -ComputerName 172.24.50.20 -Port 445

Esegui entrambe le prove da CLIENT1. Ping verifica le risposte del protocollo Internet Control Message Protocol (ICMP); una risposta bloccata non dimostra che tutti i servizi siano inattivi. Test-NetConnection con -Port verifica una connessione Transmission Control Protocol (TCP): controlla TcpTestSucceeded per quella destinazione e porta, come nella documentazione della diagnosi delle connessioni. TCP 445 serve alla condivisione di file tramite Server Message Block (SMB). Aspettati un risultato positivo solo se FS1 offre già il servizio su .20; in questa fase potrebbe non essere ancora predisposto. True non verifica autenticazione, autorizzazioni di condivisione o lettura di un file.

Se il guasto è nella stessa subnet, controlla macchine virtuali accese, collegamento allo switch, IP duplicati e maschere. Se falliscono solo destinazioni esterne, esamina gateway reale, route, traduzione degli indirizzi di rete (NAT, Network Address Translation) e regole in uscita. Non inventare un router per una rete isolata. Prima di provare un’altra porta, verifica che debba esserci un servizio in ascolto. Esamina profilo, indirizzi sorgente ammessi e destinazione delle regole firewall pertinenti senza disattivare globalmente il firewall.

Confronta il DNS esplicito e la risoluzione predefinita

Resolve-DnsName 'fs1.lab.example.test' -Type A -Server 172.24.50.10
nslookup fs1.lab.example.test 172.24.50.10
Resolve-DnsName 'fs1.lab.example.test' -Type A

Su CLIENT1, le prime due query indicano esplicitamente DC1, 172.24.50.10; l’ultima usa la risoluzione configurata del client. Se il record A di fs1.lab.example.test esiste, l’indirizzo risolto atteso è 172.24.50.20: non confonderlo con l’indirizzo del server DNS visualizzato. Nslookup non usa la cache DNS del client. Se la query mirata funziona e quella predefinita fallisce, verifica DNS, adattatori, criteri e cache: è un indizio, non la dimostrazione di una singola causa. Se funziona il nome di dominio completo (FQDN, Fully Qualified Domain Name) ma non il nome breve, controlla suffisso ed elenco di ricerca.

Distingui NXDOMAIN, che indica un nome inesistente, da un timeout senza risposta; può anche esistere il nome senza il tipo di record richiesto. Abbina i controlli DNS del client ai controlli di zone e inoltri sul server. Clear-DnsClientCache svuota la cache del client locale, mentre Clear-DnsServerCache agisce sulla cache del servizio server DNS. Anche DC1 ha ruoli client e server distinti. Identifica la cache pertinente e conserva le osservazioni prima di svuotarla: nessuna delle due operazioni corregge un record sbagliato nella zona autoritativa. Per problemi limitati ai nomi esterni, controlla inoltri e percorso in uscita senza sostituire il DNS interno con uno pubblico.

Controlla DHCP e ripeti la stessa prova

Su DC1, apri Windows PowerShell come amministratore e interroga il server locale con il blocco seguente. Verifica DHCPServer come Running, l’ambito 172.24.50.0 attivo, la capacità disponibile e il lease del client effettivo. Controlla inoltre l’associazione all’interfaccia del laboratorio e, soltanto se esiste un dominio, l’autorizzazione in Active Directory. La guida generale alla diagnosi DHCP descrive queste verifiche. Per client in un’altra subnet può servire un agente relay DHCP; non aggiungerlo per risolvere un problema nel laboratorio con un unico switch.

Get-Service DHCPServer
Get-DhcpServerv4Scope
Get-DhcpServerv4ScopeStatistics -ScopeId 172.24.50.0
Get-DhcpServerv4Lease -ScopeId 172.24.50.0

Se occorre rinnovare il lease, usa la console di CLIENT1 e limita l’operazione all’adattatore previsto. Dopo una modifica, ripeti lo stesso test fallito su nome, IP o porta e controlla che le funzioni precedentemente corrette continuino a funzionare. Se non migliora, ripristina soltanto il valore modificato e conserva comando, destinazione, ora ed errore. Disattivare tutto il firewall, svuotare ogni cache e ricreare contemporaneamente l’ambito elimina indizi e rende più difficile il ripristino.

Un esempio condizionale: la query diretta a .10 risponde correttamente, quella predefinita fallisce e scopri un DNS manuale errato su CLIENT1. Annota il valore iniziale e apri ncpa.cpl → Proprietà dell’adattatore isolato → Protocollo Internet versione 4 (TCP/IPv4) → Proprietà. Correggi soltanto il valore DNS errato in 172.24.50.10, mantieni IP, maschera e gateway e ripeti entrambe le query. Se il DNS proviene da DHCP, controlla invece l’opzione 006 dell’ambito e rinnova il client, senza nascondere il problema con un’eccezione manuale. La configurazione dell’ambito e delle opzioni DHCP spiega come verificarlo.