Diagnostique les services réseau et le pare-feu Windows

L’idée reçue

« Si le pare-feu est activé, il bloque probablement tout. »

Le diagnostic doit partir des faits : adresse, passerelle, DNS, route, résolution, écoute, profil, règle et état du service. Désactiver globalement le pare-feu détruit la preuve et augmente le risque.

01Commence par le poste client en ligne de commande

hostname
whoami
ipconfig /all
route print
arp -a
nslookup dc01.corp.soria.test

Ces commandes ne corrigent rien. Elles décrivent le poste, son identité, ses interfaces, ses routes, son voisinage local et le résultat de la résolution DNS.

Construis une première fiche de faits :

nom du poste
adresse IPv4 / masque
passerelle
serveurs DNS
route par défaut
nom demandé
adresse renvoyée par DNS

Un échec de nslookup ne prouve pas que le réseau entier est en panne. Il peut révéler un serveur DNS incorrect, un suffixe absent, un enregistrement inexistant ou une indisponibilité du service DNS.

02Reproduis la collecte avec PowerShell

Get-NetIPConfiguration
Get-DnsClientServerAddress -AddressFamily IPv4
Get-NetRoute -AddressFamily IPv4 |
  Sort-Object RouteMetric |
  Select-Object ifIndex,DestinationPrefix,NextHop,RouteMetric
Resolve-DnsName dc01.corp.soria.test -ErrorAction SilentlyContinue

L’objectif n’est pas d’opposer CMD et PowerShell. Le premier reste utile sur de nombreux postes et procédures de support ; le second facilite filtrage, automatisation et conservation des preuves.

03Suis une échelle de diagnostic

1. interface active ?
2. adresse cohérente ?
3. passerelle et route présentes ?
4. DNS correct ?
5. nom résolu ?
6. port distant joignable ?
7. service local ou distant en écoute ?
8. pare-feu cohérent ?
9. événement expliquant l'échec ?

Ne saute pas directement à l’étape 8. Une règle de pare-feu correcte ne répare ni une mauvaise adresse ni un service arrêté.

04Identifie le profil actif

Get-NetConnectionProfile
Get-NetFirewallProfile |
  Select-Object Name, Enabled, DefaultInboundAction,
                DefaultOutboundAction

Pour une lecture complémentaire depuis la ligne de commande :

netsh advfirewall show allprofiles

05Observe les écoutes locales

Get-NetTCPConnection -State Listen |
  Sort-Object LocalPort |
  Select-Object LocalAddress, LocalPort, OwningProcess

Get-Process -Id (Get-NetTCPConnection -State Listen |
  Select-Object -First 1 -ExpandProperty OwningProcess)

06Teste la connectivité utile

Test-NetConnection localhost -Port 53
Test-NetConnection 10.20.10.20 -Port 53 -InformationLevel Detailed

Un test échoué ne prouve pas immédiatement un blocage firewall. Le service peut ne pas écouter, l’adresse être incorrecte ou le routage absent.

Si le trajet réseau doit être observé :

tracert -d 10.20.10.20

L’option -d évite de mélanger le diagnostic de routage avec des résolutions de noms supplémentaires.

07Inspecte les règles applicables

Get-NetFirewallRule -Enabled True |
  Where-Object Direction -eq 'Inbound' |
  Select-Object DisplayName, Action, Profile

Get-NetFirewallPortFilter |
  Where-Object LocalPort -in 53,67,68 |
  Format-Table Protocol, LocalPort, RemotePort

08Crée une règle de test en simulation

New-NetFirewallRule \
  -DisplayName 'SORIA-Lab-DNS-TCP' \
  -Direction Inbound -Action Allow \
  -Protocol TCP -LocalPort 53 \
  -Profile Private -WhatIf

Dans la VM de laboratoire, retire -WhatIf seulement si le service existe et si la portée de la règle est justifiée.

09Corrèle avec les services et événements

Get-Service DNS,DHCPServer -ErrorAction SilentlyContinue
Get-WinEvent -FilterHashtable @{
  LogName = 'System'
  StartTime = (Get-Date).AddHours(-2)
} | Where-Object ProviderName -Match 'Service Control Manager|DNS|DHCP' |
  Select-Object TimeCreated, Id, LevelDisplayName,
                ProviderName, Message

10Écris une conclusion qui sépare fait et hypothèse

FAIT
Le client utilise 10.20.10.53 comme DNS.

FAIT
Resolve-DnsName échoue pour dc01.corp.soria.test.

HYPOTHÈSE
Le service DNS est indisponible ou l'enregistrement n'existe pas.

TEST DISCRIMINANT
Tester le port 53 puis interroger un enregistrement connu.

CORRECTION
Seulement après confirmation de la cause.

Cette discipline évite les corrections au hasard et prépare les scénarios d’évaluation BTS.

11Nettoie une règle de lab

Remove-NetFirewallRule -DisplayName 'SORIA-Lab-DNS-TCP' -WhatIf

Challenge autonome

Isoler une panne de poste client

Pars d’un symptôme « le poste n’accède pas au service ». Produis d’abord la collecte CMD, puis la collecte PowerShell. Construis ensuite un arbre de diagnostic couvrant adresse, route, DNS, port, écoute, service, pare-feu, événements, hypothèse confirmée, correction bornée et preuve après correction.

✓Lot 2 terminé

Tu sais maintenant passer d’un diagnostic de poste client à l’analyse du service : collecter les faits, isoler réseau, DNS, route, port, service et pare-feu, puis corriger seulement après confirmation de la cause.