Windows Server 2025 / Diagnostiquer les problèmes IP, DNS et DHCP

Pour diagnostiquer une panne réseau sous Windows Server 2025, distinguez l’adressage IP, le routage, la résolution DNS et l’accès au service concerné. Enregistrez les paramètres actuels du client, comparez-les avec un cas connu fonctionnel et ne changez qu’un seul élément pertinent avant de répéter le même test.

Définissez la panne et les changements récents

Identifiez si tous les clients échouent, si un seul échoue, si les noms échouent mais que les adresses fonctionnent, ou si un service échoue. Enregistrez les redémarrages récents, les modifications des commutateurs virtuels et les modifications des options DHCP (Dynamic Host Configuration Protocol, attribution automatique des adresses IP). Modifier le DNS et le pare-feu en même temps empêche de savoir quel changement a eu un effet.

L’accès par adresse IP peut modifier les vérifications de certificat ou la méthode d’authentification Kerberos du domaine par rapport à l’accès par nom. Un test de diagnostic n'est pas nécessairement une méthode de connexion permanente appropriée.

Lisez la configuration réelle du client

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

À la console de CLIENT1, exécutez ces commandes et notez l’adresse IP, le masque, le serveur DNS, le serveur DHCP et le suffixe DNS. Si l’étendue de la leçon précédente est active, attendez une adresse 172.24.50.100–172.24.50.150 et le DNS 172.24.50.10. Un réseau isolé sans routeur peut communiquer à l'intérieur de son sous-réseau sans passerelle.

Une adresse 169.254.x.x suggère un échec d'acquisition du bail sans prouver un serveur DHCP défectueux. Vérifiez d’abord le commutateur virtuel, l’état de la carte et la configuration automatique du client. Consultez la procédure de diagnostic du client DHCP pour les journaux pertinents.

Séparez la connectivité réseau de l’accès aux services

ping 172.24.50.10
Test-NetConnection -ComputerName 172.24.50.20 -Port 445

La commande ping utilise ICMP (Internet Control Message Protocol) ; si ce trafic est bloqué, son échec ne prouve pas que tous les services sont indisponibles. Le port TCP 445 vérifie seulement l’accès au service SMB (Server Message Block, partage de fichiers) lorsque FS1 l’héberge ; il ne vérifie pas les autorisations du partage.

Pour les pannes sur le même sous-réseau, inspectez l’état de la machine virtuelle (VM), le commutateur, les adresses IP en double et les masques. Pour une panne uniquement externe, inspectez la passerelle réelle et la traduction d’adresses NAT. Avant de tester un autre port, confirmez qu'un service correspondant est censé écouter.

Interrogez un résolveur précis et comparez avec les paramètres par défaut

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

Les premières requêtes utilisent explicitement DC1 ; la dernière utilise le chemin de résolution configuré par le client. Si la requête visant DC1 réussit mais que la requête par défaut échoue, examinez les paramètres du client, les stratégies et le cache. Si un nom de domaine complet (FQDN) fonctionne, mais pas le nom court, vérifiez le suffixe de recherche DNS du client.

Distinguez les réponses de nom inexistant des délais d’attente. Utilisez les vérifications DNS du client en parallèle avec les contrôles côté serveur des zones et de la récursion. Clear-DnsClientCache affecte le client local ; Clear-DnsServerCache affecte le serveur. Aucun des deux ne corrige un enregistrement autoritatif incorrect.

Vérifiez DHCP et répétez le test initial

Sur DC1, dans Windows PowerShell ouvert en tant qu’administrateur, inspectez le service DHCP, l’étendue active, les adresses disponibles, la liaison à la carte réseau et, si le domaine existe, son autorisation Active Directory. Les clients d’un autre sous-réseau peuvent nécessiter un relais DHCP ; ce laboratoire sur un seul commutateur virtuel n’en a pas besoin.

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

Renouvelez le bail depuis la console de CLIENT1 avec ipconfig /renew, après avoir enregistré sa configuration précédente. Corrigez un seul paramètre lié au symptôme, puis répétez exactement le même test de nom, d’adresse IP ou de port et contrôlez que les fonctions qui marchaient fonctionnent toujours. En cas d’échec, revenez seulement sur ce changement et conservez la commande, la cible, l’heure et l’erreur. La désactivation générale du pare-feu, le vidage indiscriminé du cache et la recréation de l’étendue compliquent le diagnostic et la récupération.