Quand le réseau Windows casse, il le fait rarement avec élégance. Une minute vous êtes sur le VPN, la suivante l’icône indique « Connected, no internet », les appels Teams ressemblent à un sous‑marin, et votre tableau de bord de supervision fait comme si de rien n’était parce que l’hôte peut toujours se pinguer lui‑même.
La tentation est d’appuyer sur le gros bouton rouge : « Network reset », des incantations netsh au hasard, redémarrer, espérer. Parfois ça marche. Parfois ça transforme un problème local en panne globale—surtout sur des machines avec clients VPN, commutateurs virtuels, Hyper‑V, WSL2, ou hooks de sécurité endpoint. Ce guide est la méthode sensée : réinitialiser la pile réseau avec PowerShell de manière propre, délibérée et réversible.
Ce que signifie réellement « réinitialiser la pile réseau »
On dit « réinitialiser le réseau » comme on dit « redémarrer le serveur ». Ce n’est pas une action unique. Sur Windows, la « pile réseau » est un empilement de couches interactives avec de l’état à plusieurs endroits :
- Configuration d’interface : adresses IP, routes, serveurs DNS, MTU, état DHCP.
- Paramètres TCP/IP : paramètres globaux comme auto‑tuning, ECN, RSS, offloads. Certains sont par interface.
- Catalogue Winsock : là où des Layered Service Providers (LSPs) s’accrochaient aux appels socket ; aujourd’hui beaucoup de produits utilisent WFP, mais les remises à zéro de Winsock restent dans les playbooks.
- Cache client DNS et NRPT : la résolution de noms est à la fois cache client et politique (surtout avec VPN).
- Configuration du proxy : WinINET/WinHTTP et paramètres PAC ; peuvent casser « internet » alors que les sockets bruts fonctionnent encore.
- Profils et règles du pare‑feu : pas strictement « pile réseau », mais suffisamment proche pour que les réinitialisations interfèrent souvent.
- Commutateurs et adaptateurs virtuels : vSwitch Hyper‑V, vEthernet WSL2, adaptateurs VPN, pilotes de filtre d’agent endpoint.
Une « réinitialisation » peut signifier :
- Réinitialisation douce : vider les caches, renouveler les baux, redémarrer les adaptateurs, réinitialiser le proxy. Faible risque, bon retour sur investissement.
- Réinitialisation moyenne : réinitialiser Winsock et les paramètres TCP/IP aux valeurs par défaut, reconstruire des parties de la pile, redémarrer des services. Parfois nécessite un redémarrage. Peut perturber les intégrations VPN/EDR.
- Réinitialisation complète : supprimer et réinstaller les adaptateurs, effacer les profils, supprimer les routes persistantes, réinitialiser les politiques de pare‑feu, l’option « Network reset » de l’UI. Efficace, mais vous venez d’effacer des preuves et possiblement des configurations critiques pour l’activité.
L’état d’esprit en production est simple : commencez par des actions observables et réversibles. Montez en puissance seulement si vous ne pouvez pas prouver le mode de défaillance ou si vous avez atteint un état connu comme mauvais. Et laissez toujours une trace pour la personne suivante—souvent vous, mais de mauvaise humeur.
Avant de toucher quoi que ce soit: périmètre, sauvegardes et rayon d’impact
Réinitialiser le réseau sur une machine Windows, c’est comme changer les pneus d’une voiture en marche—sauf que la voiture est en conférence et les passagers sont vos dirigeants. Ne touchez rien à l’aveugle.
Décidez du périmètre : machine, utilisateur, application ou trajet ?
Si une seule application est en panne, ne « réinitialisez pas la pile » en premier. Prouvez que ce n’est pas au niveau de l’application (paramètres proxy, magasin de certificats, VPN par application, DNS obsolète dans l’application). Si un seul utilisateur est affecté sur un système partagé, suspectez le proxy par utilisateur/WPAD, les credentials, ou des outils VPN spécifiques au profil.
Sachez ce que « réversible » signifie en réseau Windows
Réversible ne veut pas dire « bouton annuler ». Cela signifie que vous avez assez d’état capturé pour reconstruire :
- Configuration IP/DNS d’interface (DHCP vs statique)
- Routes (en particulier les routes persistantes)
- Suffixe DNS/liste de recherche
- Paramètres proxy (WinINET et WinHTTP)
- Politiques liées au VPN (NRPT) et noms d’adaptateurs
- Propriétés avancées d’adaptateur que vous avez ajustées volontairement
La plupart des scripts « network reset » zappent cela et vous obtenez le ticket suivant : « Tout marche sauf l’appli métier qui a besoin d’une route statique vers un sous‑réseau bizarre. » Ce sous‑réseau restera toujours bizarre. Il faut toujours y router.
Réalité administrative
Beaucoup d’opérations requièrent des droits élevés. Si vous êtes sur un endpoint géré par l’entreprise, certaines actions seront bloquées par la politique ou annulées par des agents de management ensuite. Faites-en votre paix. Votre travail est de diagnostiquer et d’appliquer le changement minimal qui persiste.
Une citation, parce qu’elle est vraie
« L’espoir n’est pas une stratégie. » — Général Gordon R. Sullivan
Les « réinitialisations » réseau motivées par l’espoir expliquent pourquoi vous redémarrez cinq fois et appelez toujours ça « intermittent ».
Plan de diagnostic rapide (trouver le goulot en quelques minutes)
C’est l’ordre qui gagne en production : identifiez rapidement si vous avez affaire à la couche liaison, IP, résolution de noms, routage, proxy ou filtrage. Vous n’êtes pas là pour « essayer des choses ». Vous êtes là pour pointer la couche fautive.
Première étape : l’interface est‑elle réellement up et saine ?
- Vérifiez l’état de l’adaptateur, la vitesse et si la bonne NIC est utilisée.
- Confirmez que vous avez une IP (IPv4 et/ou IPv6) et une passerelle par défaut comme attendu.
Deuxième étape : pouvez‑vous atteindre la passerelle et quelque chose au‑delà ?
- Pinger la passerelle (atteignabilité L2/L3 locale).
- Pinger une IP externe (routage/NAT/amont).
- Faire un traceroute si le ping ment (les pare‑feux rendent le ping peu fiable).
Troisième étape : le DNS est‑il en cause (souvent oui) ?
- Résoudre un nom connu via le serveur DNS configuré.
- Comparer résolution de noms et connectivité IP brute.
- Vider le cache DNS seulement après avoir capturé des preuves.
Quatrième étape : un proxy ou une politique VPN ne détourne‑t‑il pas le trafic ?
- Vérifier le proxy WinHTTP et le proxy utilisateur.
- Vérifier les routes VPN et les règles NRPT (split tunnel vs full tunnel).
Cinquième étape : un filtrage est‑il en cause (pare‑feu, EDR, WFP, pilote) ?
- Recherchez des chutes soudaines après une mise à jour spécifique.
- Vérifiez le profil du pare‑feu et les règles de base en sortie.
- Si tout « semble correct » mais que rien ne fonctionne, suspectez un pilote de filtre ou un mauvais ordre de liaison.
Si vous suivez cet ordre, vous éviterez typiquement le pire comportement : réinitialiser cinq sous‑systèmes alors qu’un fichier PAC WPAD obsolète était le vrai coupable.
Faits intéressants et contexte historique
Six à dix petits faits pour vous aider à raisonner pourquoi le réseau Windows se comporte comme il le fait :
- Les réinitialisations Winsock sont une relique qui compte encore. Les Layered Service Providers (LSPs) étaient courants pour intercepter les sockets ; les outils de sécurité modernes utilisent souvent WFP, mais le catalogue Winsock peut encore être corrompu ou mal ordonné.
netshprécède PowerShell de plusieurs années. L’automatisation réseau Windows vivait dansnetshbien avant que PowerShell devienne l’interface standard. Beaucoup de correctifs « PowerShell » appellent encorenetshcar il est éprouvé.- Windows préfère IPv6 quand il le peut. Les systèmes dual‑stack essaieront souvent les enregistrements AAAA en premier. « IPv6 est cassé » peut se manifester comme « internet est lent », pas comme « IPv6 est down ».
- DNS sur Windows n’est pas seulement DNS. Le résolveur mélange cache, listes de suffixes, LLMNR, mDNS (plus récent), et règles basées sur la politique (NRPT). Une mauvaise politique peut rendre les noms internes inaccessibles alors que les noms publics fonctionnent.
- La fonction UI « Network reset » est assez récente. C’est une commodité apparue avec Windows 10+ qui supprime et réinstalle les adaptateurs et réinitialise des composants. C’est aussi une excellente façon de perdre le routage personnalisé et les liaisons VPN.
- L’auto‑tuning TCP a fait polémique. Lors de l’introduction du Receive Window Auto‑Tuning, le débit s’est amélioré sur beaucoup de liaisons mais a causé des comportements étranges avec certains middleboxes. Le désactiver est devenu une médecine populaire ; parfois ça aidait, souvent ça réduisait juste les performances.
- Les paramètres proxy vivent dans deux mondes. Le proxy WinINET est en contexte utilisateur et utilisé par les navigateurs ; le proxy WinHTTP est en contexte machine et utilisé par les services. Réinitialiser l’un sans l’autre produit la comédie « marche dans le navigateur, échoue dans le service ».
- Le routage basé sur métrique a généralement raison… jusqu’à ce qu’il ait tort. Windows choisit les routes selon la longueur de préfixe et les métriques. Ajoutez un adaptateur VPN et soudain votre route par défaut change. Les gens appellent ça « aléatoire ». Ce n’est pas aléatoire. C’est déterministe et gênant.
- La sécurité endpoint adore la pile réseau. Beaucoup d’EDR installent des pilotes de filtre et des callouts WFP. Une « réinitialisation » qui réordonne les liaisons ou réinitialise des catalogues peut casser ces intégrations—temporairement ou jusqu’à la réparation par l’agent.
Tâches pratiques (commandes, sorties, décisions)
Ci‑dessous des tâches pratiques que vous pouvez exécuter depuis un PowerShell élevé. Les blocs de code montrent des commandes réalistes et des sorties plausibles. Après chaque tâche : ce que la sortie signifie et quelle décision prendre.
Task 1: Confirm you’re elevated (don’t guess)
cr0x@server:~$ powershell -NoProfile -Command "[Security.Principal.WindowsPrincipal]::new([Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)"
True
Ce que cela signifie : True indique un contexte Administrateur. Beaucoup d’actions de réinitialisation échoueront silencieusement ou s’appliqueront partiellement sans cela.
Décision : Si False, rouvrez PowerShell en « Exécuter en tant qu’administrateur ». N’allez pas plus loin. Les réinitialisations partielles sont la façon de créer des cassures uniques et non reproductibles.
Task 2: Capture current interface configuration (your rollback seed)
cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPConfiguration | Format-List InterfaceAlias,InterfaceIndex,IPv4Address,IPv6Address,DNSServer,IPv4DefaultGateway,NetProfile.Name"
InterfaceAlias : Ethernet0
InterfaceIndex : 12
IPv4Address : 10.20.14.55
IPv6Address : fe80::b9f1:7c2a:7c2d:aa11
DNSServer : {10.20.0.10, 10.20.0.11}
IPv4DefaultGateway : 10.20.14.1
NetProfile.Name : CorpLAN
Ce que cela signifie : Cela vous dit à quoi ressemblait le « bon » état avant de toucher quoi que ce soit : IP, gateway, serveurs DNS et quel profil Windows pense utiliser.
Décision : Sauvegardez‑le (copier/coller dans le ticket, ou exporter en fichier). Si vous ne voyez pas de passerelle par défaut, ce n’est pas encore un problème de « reset »—réparez d’abord la config DHCP/statique.
Task 3: Identify the active route choice (default route tells stories)
cr0x@server:~$ powershell -NoProfile -Command "Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Sort-Object RouteMetric,InterfaceMetric | Format-Table ifIndex,InterfaceAlias,NextHop,RouteMetric,InterfaceMetric -Auto"
ifIndex InterfaceAlias NextHop RouteMetric InterfaceMetric
------ -------------- ------- ----------- --------------
12 Ethernet0 10.20.14.1 0 25
28 VPN-Corp 0.0.0.0 10 5
Ce que cela signifie : Vous avez des routes par défaut concurrentes. Ici, l’adaptateur VPN a une métrique totale plus faible et peut voler le trafic. Cela peut être voulu (full tunnel) ou catastrophique (split tunnel attendu).
Décision : Si les symptômes sont apparus « après la connexion VPN », ne réinitialisez pas la pile—corrigez l’intention de routage/métrique. Si le VPN doit être split tunnel, vérifiez la config VPN et poussez les routes correctement.
Task 4: Basic connectivity: gateway then external IP
cr0x@server:~$ powershell -NoProfile -Command "Test-Connection -Count 2 10.20.14.1"
Source Destination IPV4Address IPV6Address Bytes Time(ms)
------ ----------- ----------- ----------- ----- --------
WIN-CLIENT01 10.20.14.1 10.20.14.1 32 2
WIN-CLIENT01 10.20.14.1 10.20.14.1 32 2
cr0x@server:~$ powershell -NoProfile -Command "Test-Connection -Count 2 1.1.1.1"
Source Destination IPV4Address IPV6Address Bytes Time(ms)
------ ----------- ----------- ----------- ----- --------
WIN-CLIENT01 1.1.1.1 1.1.1.1 32 16
WIN-CLIENT01 1.1.1.1 1.1.1.1 32 15
Ce que cela signifie : Le routage L3 vers Internet est OK (au moins ICMP fonctionne). Si des applications échouent encore, suspectez DNS/proxy/filtres.
Décision : Si la passerelle échoue, ne touchez pas Winsock—votre problème est la liaison locale/VLAN/DHCP/config statique. Si la passerelle marche mais l’IP externe échoue, suspectez le routage amont, le pare‑feu, ou la capture de route par le VPN.
Task 5: DNS resolution test that actually tells you something
cr0x@server:~$ powershell -NoProfile -Command "Resolve-DnsName -Name example.com -Server 10.20.0.10 | Select-Object -First 2"
Name Type TTL Section IPAddress
---- ---- --- ------- ---------
example.com A 60 Answer 93.184.216.34
example.com A 60 Answer 93.184.216.34
Ce que cela signifie : Le serveur DNS répond et retourne des enregistrements. Si vous pouvez pinguer 1.1.1.1 mais que DNS échoue, votre problème est la reachabilité DNS, la politique DNS, ou l’état du client DNS.
Décision : Si cela échoue par timeout, vérifiez si le serveur DNS est joignable et si le VPN ou le pare‑feu bloque UDP/TCP 53. Si ça renvoie « NXDOMAIN » pour des noms internes, examinez la liste de suffixes et le NRPT.
Task 6: Check DNS client cache (and don’t flush blindly)
cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientCache | Select-Object -First 5"
Entry RecordName RecordType TimeToLive Data
----- ---------- ---------- ---------- ----
example.com example.com A 00:00:41 93.184.216.34
wpad wpad A 00:05:00 10.20.0.50
intranet intranet A 00:00:12 10.20.8.20
Ce que cela signifie : Vous pouvez voir des entrées en cache comme wpad. WPAD est une source fréquente de « seules les applis web sont cassées ».
Décision : Si vous voyez des entrées suspectes (mauvaise IP pour intranet, wpad obsolète), videz le cache après l’avoir capturé, puis retestez la résolution. Si le mauvais résultat revient immédiatement, le problème est en amont DNS/politique, pas le cache local.
Task 7: Inspect proxy state (WinINET vs WinHTTP)
cr0x@server:~$ powershell -NoProfile -Command "netsh winhttp show proxy"
Current WinHTTP proxy settings:
Proxy Server(s) : 10.20.0.60:8080
Bypass List : (none)
cr0x@server:~$ powershell -NoProfile -Command "Get-ItemProperty 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings' | Select-Object ProxyEnable,ProxyServer,AutoConfigURL"
ProxyEnable ProxyServer AutoConfigURL
----------- ----------- -------------
1 10.20.0.60:8080 http://wpad/wpad.dat
Ce que cela signifie : Les contextes machine et utilisateur pointent vers un proxy/PAC. Si ce proxy est injoignable, les navigateurs et beaucoup d’apps échoueront alors que le ping fonctionne.
Décision : Si le proxy n’est pas requis sur ce réseau, réinitialisez‑le (prudemment). S’il est requis, testez la reachabilité du proxy et validez la résolution du PAC.
Task 8: Check whether the DNS client service is healthy
cr0x@server:~$ powershell -NoProfile -Command "Get-Service Dnscache | Format-Table Status,StartType,Name -Auto"
Status StartType Name
------ --------- ----
Running Automatic Dnscache
Ce que cela signifie : Si Dnscache est arrêté/désactivé, la résolution de noms devient inconsistante et plus lente ; certaines APIs se comportent différemment.
Décision : Si ce n’est pas en cours, démarrez‑le et investigatez pourquoi il a été désactivé (politique de durcissement ? outil « optimiseur » ?). Ne réinitialisez pas TCP/IP pour réparer un service arrêté.
Task 9: Observe TCP global settings before “tuning” anything
cr0x@server:~$ powershell -NoProfile -Command "netsh int tcp show global"
Querying active state...
TCP Global Parameters
----------------------------------------------
Receive-Side Scaling State : enabled
Receive Window Auto-Tuning Level : normal
Add-On Congestion Control Provider : default
ECN Capability : disabled
RFC 1323 Timestamps : disabled
Ce que cela signifie : Ce sont des comportements TCP globaux. « Réinitialiser TCP/IP » peut rétablir certains items ; les « optimiseurs » les modifient souvent.
Décision : Si quelqu’un a précédemment mis l’auto‑tuning sur disabled ou changé le fournisseur de congestion « pour les performances », traitez‑le comme suspect. Mais ne le changez pas juste parce qu’un post dans un forum le recommande.
Task 10: Identify adapter drivers and recent changes
cr0x@server:~$ powershell -NoProfile -Command "Get-NetAdapter | Select-Object Name,Status,LinkSpeed,DriverInformation | Format-List"
Name : Ethernet0
Status : Up
LinkSpeed : 1 Gbps
DriverInformation : Intel(R) Ethernet Connection (11) I219-LM #4
Name : VPN-Corp
Status : Up
LinkSpeed : 100 Mbps
DriverInformation : WAN Miniport (IKEv2)
Ce que cela signifie : « Up » ne veut pas dire « sain », mais c’est un début. L’identité du pilote compte : les vendeurs NIC fournissent des fonctionnalités d’offload avancées qui peuvent échouer après des mises à jour.
Décision : Si le problème a commencé après une mise à jour de pilote, concentrez‑vous là‑dessus. Les réinitialisations de pile ne répareront pas un pilote buggué ou une liaison de filtre cassée.
Task 11: Restart a single adapter (low risk, surprisingly effective)
cr0x@server:~$ powershell -NoProfile -Command "Restart-NetAdapter -Name 'Ethernet0' -Confirm:\$false"
Ce que cela signifie : Cela redémarre l’interface, renégocie le lien, renouvelle le DHCP dans bien des cas, et rebinde les protocoles.
Décision : Faites‑le avant de flinguer Winsock. Si le rebond de l’adaptateur règle le problème, vous avez appris que le problème était au niveau de l’interface (bail DHCP obsolète, bug du driver, bizarrerie de port de switch).
Task 12: Force DHCP renew (when you suspect a stale lease)
cr0x@server:~$ powershell -NoProfile -Command "ipconfig /release"
Windows IP Configuration
No operation can be performed on Ethernet0 while it has its media disconnected.
Ethernet0 has been released.
cr0x@server:~$ powershell -NoProfile -Command "ipconfig /renew"
Windows IP Configuration
Ethernet0 has renewed its lease.
IPv4 Address. . . . . . . . . . . : 10.20.14.55
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 10.20.14.1
Ce que cela signifie : Release/renew est brutal mais réversible. Si le renouvellement échoue, le chemin DHCP est cassé (ou 802.1X/VLAN est incorrect).
Décision : Si le renouvellement échoue, arrêtez. Réparez l’authentification L2/VLAN/reachabilité DHCP. Ne poursuivez pas avec des réinitialisations de pile ; vous serez simplement hors‑ligne de façon plus compliquée.
Task 13: Flush DNS and retest (only after evidence)
cr0x@server:~$ powershell -NoProfile -Command "ipconfig /displaydns | Select-Object -First 12"
Windows IP Configuration
example.com
----------------------------------------
Record Name . . . . . : example.com
Record Type . . . . . : 1
Time To Live . . . . : 41
Data Length . . . . . : 4
Section . . . . . . . : Answer
A (Host) Record . . . : 93.184.216.34
cr0x@server:~$ powershell -NoProfile -Command "ipconfig /flushdns"
Windows IP Configuration
Successfully flushed the DNS Resolver Cache.
Ce que cela signifie : Le cache est vidé. Si la résolution retourne immédiatement le mauvais résultat, le poison est en amont ou basé sur la politique, pas le cache local.
Décision : Si le vidage corrige et que ça reste corrigé, vous aviez un cache obsolète. Si ça revient, poursuivez avec l’analyse des réponses serveur DNS, des suffixes, du NRPT ou des paramètres DNS du VPN.
Task 14: Reset Winsock (medium impact, often requires reboot)
cr0x@server:~$ powershell -NoProfile -Command "netsh winsock show catalog | Select-String -Pattern 'Catalog5' -Context 0,2 | Select-Object -First 6"
Catalog5 01
--------
Packed Catalog Item
Description: MSAFD Tcpip [TCP/IP]
cr0x@server:~$ powershell -NoProfile -Command "netsh winsock reset"
Successfully reset the Winsock Catalog.
You must restart the computer in order to complete the reset.
Ce que cela signifie : Le catalogue Winsock est reconstruit par défaut. Cela peut casser ou réparer des logiciels qui crochetent les sockets. L’exigence de redémarrer est réelle.
Décision : Faites‑le seulement après avoir écarté les problèmes simples de proxy/DNS/interface. Si la machine est critique, planifiez le redémarrage. Ne le faites pas en plein incident sur l’ordinateur du CEO à moins d’aimer l’adrénaline.
Task 15: Reset TCP/IP stack parameters (bigger hammer)
cr0x@server:~$ powershell -NoProfile -Command "netsh int ip reset"
Resetting Global, OK!
Resetting Interface, OK!
Resetting Neighbor, OK!
Resetting Path, OK!
Resetting , OK!
Restart the computer to complete this action.
Ce que cela signifie : Cela réinitialise beaucoup de paramètres TCP/IP dans le registre. Cela peut réparer une corruption ou de mauvais réglages. Cela peut aussi supprimer des optimisations délibérées et certains motifs de configuration statique.
Décision : Ne faites‑le que si vous avez documenté l’état courant et que vous êtes prêt à restaurer les adresses statiques et les routes ensuite.
Task 16: Reset WinHTTP proxy (common “internet broken” fix)
cr0x@server:~$ powershell -NoProfile -Command "netsh winhttp reset proxy"
Current WinHTTP proxy settings:
Direct access (no proxy server).
Ce que cela signifie : Le proxy en contexte machine est effacé. Les services qui dépendent de WinHTTP peuvent reprendre immédiatement.
Décision : Si vous êtes dans un environnement d’entreprise qui impose un proxy, ne l’effacez pas définitivement—configurez‑le correctement. Mais la réinitialisation est un bon pas de diagnostic : si les services se remettent à marcher, votre chemin proxy est l’incident réel.
Task 17: Capture and restore persistent routes (the easy-to-forget outage)
cr0x@server:~$ powershell -NoProfile -Command "route print -4 | Select-String -Pattern 'Persistent Routes' -Context 0,8"
Persistent Routes:
Network Address Netmask Gateway Address Metric
10.50.0.0 255.255.0.0 10.20.14.254 1
cr0x@server:~$ powershell -NoProfile -Command "Get-NetRoute -PolicyStore PersistentStore | Format-Table DestinationPrefix,NextHop,RouteMetric,InterfaceAlias -Auto"
DestinationPrefix NextHop RouteMetric InterfaceAlias
----------------- ------- ----------- --------------
10.50.0.0/16 10.20.14.254 1 Ethernet0
Ce que cela signifie : Des routes persistantes existent et comptent. Une « réinitialisation complète » ou une réinstallation d’adaptateur peut les supprimer, et l’appli métier derrière 10.50.0.0/16 mourra silencieusement.
Décision : Exports‑les avant les réinitialisations. Après celles‑ci, réappliquez‑les avec New-NetRoute -PolicyStore PersistentStore si nécessaire.
Task 18: Quick port/path test (prove it’s not just ICMP)
cr0x@server:~$ powershell -NoProfile -Command "Test-NetConnection -ComputerName 10.20.0.10 -Port 53"
ComputerName : 10.20.0.10
RemoteAddress : 10.20.0.10
RemotePort : 53
InterfaceAlias : Ethernet0
SourceAddress : 10.20.14.55
TcpTestSucceeded : True
cr0x@server:~$ powershell -NoProfile -Command "Test-NetConnection -ComputerName 10.20.0.60 -Port 8080"
ComputerName : 10.20.0.60
RemoteAddress : 10.20.0.60
RemotePort : 8080
InterfaceAlias : Ethernet0
SourceAddress : 10.20.14.55
TcpTestSucceeded : False
Ce que cela signifie : Le serveur DNS est joignable sur TCP 53 ; le port proxy 8080 ne l’est pas. Ça explique « web apps mortes » sans toucher aux réinitialisations IP.
Décision : Réparez la reachabilité du proxy ou les règles de contournement. Ne réinitialisez pas Winsock parce qu’un serveur proxy est down.
C’est beaucoup de commandes, et oui, c’est volontaire. Réinitialiser la pile doit être la fin d’une courte chaîne de diagnostic, pas la première étape d’un script de soutien émotionnel.
Listes de contrôle / plan étape par étape : réinitialisation propre et réversible
Ceci est le playbook en production. Ce n’est pas la façon la plus rapide de « faire quelque chose ». C’est la façon la plus rapide d’arrêter de faire la mauvaise chose.
Checklist A: Capture state (do this every time)
- Capturez la config d’interface : IP, DNS, gateway, profil.
- Capturez les routes, y compris les routes persistantes.
- Capturez les paramètres client DNS (liste de suffixes, serveurs).
- Capturez l’état du proxy (WinINET + WinHTTP).
- Notez l’état VPN et la liste des adaptateurs.
cr0x@server:~$ powershell -NoProfile -Command "New-Item -ItemType Directory -Force C:\Temp\net-reset | Out-Null; Get-Date | Out-File C:\Temp\net-reset\timestamp.txt; Get-NetIPConfiguration | Out-File C:\Temp\net-reset\netipconfig.txt; Get-NetRoute | Out-File C:\Temp\net-reset\netroutes.txt; Get-DnsClientServerAddress | Out-File C:\Temp\net-reset\dns-servers.txt; netsh winhttp show proxy | Out-File C:\Temp\net-reset\winhttp-proxy.txt; Get-ItemProperty 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings' | Out-File C:\Temp\net-reset\wininet-proxy.txt; Get-NetAdapter | Out-File C:\Temp\net-reset\netadapters.txt"
Ce que cela signifie : Vous avez maintenant un instantané que vous pouvez comparer après le changement. Si votre modification a empiré la situation, vous pouvez restaurer intelligemment au lieu d’« annuler » au hasard.
Checklist B: Soft reset (safe first moves)
- Redémarrer l’adaptateur affecté.
- Renouveler le bail DHCP (seulement si DHCP est utilisé).
- Vider le cache DNS (après capture de preuves).
- Réinitialiser le proxy WinHTTP (diagnostique).
- Redémarrer le service client DNS si bloqué.
cr0x@server:~$ powershell -NoProfile -Command "Restart-NetAdapter -Name 'Ethernet0' -Confirm:\$false; ipconfig /renew; ipconfig /flushdns; netsh winhttp reset proxy; Restart-Service Dnscache -Force"
Windows IP Configuration
Ethernet0 has renewed its lease.
Successfully flushed the DNS Resolver Cache.
Current WinHTTP proxy settings:
Direct access (no proxy server).
Gate de décision : Si cela résout le problème, arrêtez‑vous. Documentez ce qui a changé et pourquoi ça a fonctionné. Votre vous futur vous remerciera.
Checklist C: Medium reset (when soft reset fails)
Faites‑les quand vous avez prouvé que l’hôte a la liaison, une IP, peut atteindre la passerelle, mais que le réseau de plus haut niveau est corrompu ou détourné.
- Réinitialiser le catalogue Winsock.
- Réinitialiser les paramètres TCP/IP.
- Redémarrer (oui, redémarrer réellement).
cr0x@server:~$ powershell -NoProfile -Command "netsh winsock reset; netsh int ip reset"
Successfully reset the Winsock Catalog.
You must restart the computer in order to complete the reset.
Resetting Global, OK!
Resetting Interface, OK!
Resetting Neighbor, OK!
Resetting Path, OK!
Resetting , OK!
Restart the computer to complete this action.
Gate de décision : Si vous ne pouvez pas redémarrer, ne prétendez pas avoir réinitialisé. Planifiez une fenêtre de reboot. La pile est pleine d’état ; vous ne la surclasserez pas avec des intentions.
Checklist D: Hard reset (last resort, high blast radius)
Les réinitialisations complètes sont pour les machines avec des liaisons d’adaptateur irrémédiablement corrompues, des adaptateurs virtuels cassés, ou « tout est up mais rien ne marche » après tentatives raisonnables. Attendez‑vous à reconfigurer clients VPN, vSwitches, et routes statiques.
Plutôt que l’option « Network reset » des Paramètres Windows, je préfère d’abord des actions ciblées : supprimer les adaptateurs obsolètes, désactiver/réactiver des bindings spécifiques, et seulement alors envisager l’option totale. Si vous devez utiliser l’option nucléaire, assurez‑vous d’avoir votre snapshot de la Checklist A.
Blague n°1 : Une réinitialisation réseau complète, c’est comme « éteignez‑le et rallumez‑le », sauf qu’elle supprime aussi vos devoirs et vous demande ensuite pourquoi vous avez l’air stressé.
Trois mini‑histoires du monde de l’entreprise (comment ça se passe mal et bien)
Mini‑histoire 1 : L’incident causé par une mauvaise hypothèse
Cela a commencé comme une plainte « le VPN est lent » d’une équipe finance distante. Le laptop pouvait pinguer la passerelle VPN, résoudre le DNS interne, mais le client ERP faisait timeout. Quelqu’un a vu « Connected, no internet » sur l’icône Wi‑Fi et a conclu que la pile TCP/IP était corrompue.
La tentative de réparation fut enthousiaste : reset Winsock, reset TCP/IP, « Network reset » depuis les Paramètres, deux reboot. Réinstallation du client VPN. Toujours cassé. Et maintenant pire : la machine avait perdu une route persistante qui redirigeait le trafic ERP vers un appliance proxy interne utilisé seulement par ce département.
Nous sommes intervenus après le troisième reboot, car à ce stade « ça doit être Windows ». La piste était dans la table de routage : le VPN avait installé une route par défaut avec une métrique basse, mais le sous‑réseau ERP n’était pas inclus dans les routes split‑tunnel du VPN. Avant le reset, la route persistante cachait cela. Après le reset, elle avait disparu, donc le trafic ERP allait au mauvais endroit et mourait.
La vraie réparation fut de corriger les routes poussées par le VPN et de réajouter la route persistante temporairement. Le reset n’a pas seulement échoué à aider—il a supprimé le contournement qui compensait une mauvaise configuration en amont. La mauvaise hypothèse fut de penser que l’icône « no internet » voulait dire « TCP/IP cassé ». En réalité, Windows ne pouvait pas atteindre un endpoint de probe NCSI spécifique, ce qui n’est pas la même chose que « votre réseau est down ».
Leçon : lisez toujours les routes avant de réinitialiser. Les routes expliquent la plupart des pannes mystérieuses, et ce sont aussi les premières choses que vous effacez accidentellement.
Mini‑histoire 2 : L’optimisation qui a mal tourné
Une équipe desktop a déployé un script « optimisation latence » sur une flotte d’ordinateurs du trading floor. Il désactivait l’auto‑tuning TCP, modifiait les offloads, et mettait quelques valeurs de registre copiées depuis un post datant de l’ère Vista. L’auteur du script se sentait puissant, ce qui est rarement un bon signal pour la fiabilité.
Quelques jours passent sans notice. Puis des plaintes arrivent : applis web internes échouent par intermittence, transferts de fichiers lents, VPN instable sous charge. Les pings avaient l’air corrects. Les tests de débit étaient « ok ». Les charges réelles non.
Nous avons diffé la machine cassée contre une machine saine. L’état global TCP était le coupable : auto‑tuning désactivé, fournisseur de congestion modifié, et un mélange de paramètres d’offload d’adaptateur changés sans tenir compte des versions de pilote. Un middlebox sur le chemin n’a pas aimé ce comportement et a commencé à dropper ou réordonner le trafic sous charge.
La « correction » fut une réinitialisation—mais contrôlée. Nous avons capturé l’état, remis les globaux TCP par défaut, et appliqué seulement un changement restreint et mesurable quand c’était justifié. La plupart des « optimisations » ont été retirées. Le débit s’est amélioré, les erreurs ont chuté, et la seule chose qui a ralenti fut le rythme des nouveaux tickets.
Leçon : les tweaks de performance sans mesure sont juste des pannes avec du marketing. Réinitialiser aux valeurs par défaut est souvent le chemin le plus rapide vers l’ennui—et l’ennui est bon.
Mini‑histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la situation
Un serveur Windows en bureau de succursale commençait à échouer à résoudre des noms internes. L’équipe locale a fait le sempiternel : vider le DNS, reboot, engueuler l’ISP. Parfois ça marchait une heure, parfois non. Pendant ce temps le serveur résolvait toujours les noms publics correctement, car il pouvait atteindre le DNS public via un chemin de secours.
Quand nous sommes intervenus, il y avait déjà une pression pour « tout réinitialiser ». Au lieu de cela nous avons demandé une capture de base : config d’interface, routes, serveurs DNS, et l’erreur exacte de Resolve-DnsName contre chaque serveur DNS configuré. C’était lent, méthodique et profondément peu glamour.
Les données ont montré que le serveur était configuré avec deux serveurs DNS : un interne et un public. Le serveur interne échouait par intermittence à cause d’un flap de routage entre la succursale et le siège. Windows utilisait alors « utilement » le résolveur public, qui ne connaissait pas les zones internes. Les résolutions internes échouaient donc de façon sporadique selon le serveur interrogé à ce moment.
La réparation fut ennuyeuse : retirer le serveur DNS public, ajouter un second serveur DNS interne joignable sur un chemin stable, et corriger la route de branche. Aucune réinitialisation de pile nécessaire. La capture de base nous a empêchés de détruire la preuve et nous a permis de prouver la causalité à l’équipe réseau.
Leçon : capturez d’abord, changez ensuite. Ce n’est pas glamour, mais c’est la différence entre dépanner et pratiquer un rituel.
Erreurs courantes: symptômes → cause racine → réparation
Cette section est là où les tickets cessent d’être vagues.
1) « Connected, no internet » mais les ressources internes fonctionnent
Symptôme : Windows affiche « No internet », mais vous pouvez accéder à l’intranet ou pinguer des IP internes.
Cause racine : NCSI (Network Connectivity Status Indicator) ne peut pas atteindre son endpoint de probe, souvent à cause d’un proxy, pare‑feu ou politique DNS. Ce n’est pas nécessairement une panne réelle.
Réparation : Validez la santé réelle des chemins avec Test-NetConnection vers des cibles connues. Vérifiez les paramètres proxy et le DNS. Ne réinitialisez pas TCP/IP parce qu’une icône est mécontente.
2) Le ping fonctionne, la navigation web échoue
Symptôme : Test-Connection 1.1.1.1 fonctionne. Le navigateur n’affiche rien.
Cause racine : Mauvaise configuration proxy (PAC/WPAD), port proxy bloqué, ou proxy WinINET mal configuré.
Réparation : Inspectez WinINET et WinHTTP proxy ; testez la connectivité au port proxy ; réinitialisez le proxy pour diagnostiquer.
3) DNS fonctionne pour noms publics, échoue pour noms internes
Symptôme : Resolve-DnsName example.com fonctionne ; Resolve-DnsName intranet.corp renvoie NXDOMAIN.
Cause racine : Mauvais serveurs DNS, absence de liste de suffixes, ou règles NRPT du VPN non appliquées.
Réparation : Assurez‑vous que les serveurs DNS internes sont configurés et joignables ; vérifiez la liste de suffixes ; examinez le DNS/politique du VPN. Vider le cache n’inventera pas des zones DNS manquantes.
4) Tout casse après la connexion VPN
Symptôme : Internet local meurt avec le VPN, ou les routes internes ne fonctionnent pas.
Cause racine : La route par défaut a été détournée (full tunnel vs split tunnel), problèmes de métriques, ou routes poussées manquantes.
Réparation : Inspectez les routes par défaut et les métriques ; validez la politique de routes VPN. Ne réinitialisez pas la pile ; corrigez l’intention de routage.
5) « Le reset l’a réparé une fois, maintenant c’est de retour chaque matin »
Symptôme : Récurrence quotidienne ; un reset rapide « aide » temporairement.
Cause racine : Politique/agent qui réapplique des paramètres erronés (proxy, DNS, pare‑feu), ou pilote instable qui se réinitialise au réveil/sortie de veille.
Réparation : Identifiez le paramètre qui dérive en comparant les snapshots. Réparez la source (GPO/MDM/client VPN/pilote). Les réinitialisations répétées ne sont que la répétition programmée du même incident.
6) Après « network reset », une appli métier ne peut plus atteindre un sous‑réseau
Symptôme : La plupart des choses marchent ; un seul sous‑réseau interne est mort.
Cause racine : Routes persistantes ou configuration IP statique perdues.
Réparation : Réappliquez les routes persistantes et confirmez avec Get-NetRoute -PolicyStore PersistentStore. C’est pourquoi on capture l’état.
7) DNS lent, timeouts intermittents
Symptôme : La résolution de noms prend des secondes ; parfois échoue.
Cause racine : Premier serveur DNS injoignable, Windows bascule lentement ; ou serveur DNS VPN joignable mais surchargé.
Réparation : Testez chaque serveur DNS directement avec Resolve-DnsName -Server. Supprimez les serveurs morts ; ne vous contentez pas de vider le cache et d’appeler ça « réparé ».
8) « La réinitialisation Winsock a cassé mon client sécurité/VPN »
Symptôme : Après la réinitialisation, le VPN ou l’agent de sécurité ne se connecte plus, le filtrage réseau se comporte étrangement.
Cause racine : Le logiciel dépend d’entrées de catalogue spécifiques ou d’ordres de binding ; la réinitialisation a changé l’ordre/les valeurs par défaut.
Réparation : Réinstallez/réparez l’agent affecté, ou restaurez depuis l’état capturé si possible. Et la prochaine fois, n’allez pas direct au reset Winsock avant d’avoir vérifié proxy/DNS/routes.
Blague n°2 : Les réinitialisations Winsock sont le ruban adhésif du réseau Windows—parfois ça bouche la fuite, parfois ça devient une pièce de la plomberie.
FAQ
1) L’option « Reset this PC’s network » (Paramètres Windows) est‑elle la même que netsh winsock reset ?
Non. « Network reset » dans les Paramètres est plus large et destructeur : il supprime et réinstalle les adaptateurs et réinitialise plusieurs composants. netsh winsock reset cible spécifiquement le catalogue Winsock. Utilisez l’UI uniquement quand les réinitialisations ciblées échouent et que vous avez capturé l’état.
2) Puis‑je faire une réinitialisation propre uniquement avec PowerShell, sans netsh ?
Certaines parties, oui (redémarrage d’adaptateur, inspection config IP, gestion des routes). Mais Winsock/TCP/IP se réinitialisent encore plus fiablement avec netsh sur de nombreuses versions de Windows. Être dogmatique sur la pureté des outils est une perte de temps.
3) Quand dois‑je redémarrer ?
Quand l’outil vous le dit, et quand vous avez modifié de l’état bas‑niveau de la pile. Winsock reset et TCP/IP reset demandent fréquemment un redémarrage pour s’appliquer pleinement. Si vous ne pouvez pas redémarrer, considérez‑le comme une tentative diagnostique, pas une réinitialisation.
4) La réinitialisation cassera‑t‑elle mon VPN ?
Ça peut. Les clients VPN installent souvent des adaptateurs virtuels, des routes, des politiques DNS et parfois des composants de filtrage. Les réinitialisations douces ne font généralement pas de dégâts. Les réinitialisations moyennes/complètes peuvent forcer le client à réparer ou réinstaller. Capturez d’abord vos routes et l’état DNS pour savoir si le VPN a modifié quelque chose.
5) Je peux atteindre des IP mais pas des noms. Dois‑je réinitialiser TCP/IP ?
Généralement non. C’est typiquement la reachabilité du serveur DNS, la liste de suffixes, NRPT, ou un proxy/PAC. Commencez par Resolve-DnsName -Server et vérifiez les serveurs DNS et les routes. Réinitialiser TCP/IP est un marteau plus gros que nécessaire.
6) Quelle est la commande « première réinitialisation » la plus sûre ?
Restart-NetAdapter pour l’adaptateur affecté, suivi d’un vidage ciblé du cache DNS si vous avez des preuves de résolution obsolète. Faible rayon d’impact et souvent efficace pour effacer des bizarreries transitoires driver/DHCP.
7) Vider le cache DNS affecte‑t‑il les autres utilisateurs ou services ?
Il affecte le cache du résolveur local. Cela peut causer un pic bref de requêtes DNS quand les noms sont re‑résolus. C’est généralement sûr, mais si vous debuggez, capturez d’abord le cache pour voir ce qui n’allait pas.
8) Pourquoi certains services échouent tandis que les navigateurs fonctionnent (ou inversement) ?
Contexte proxy. Les navigateurs utilisent souvent WinINET (paramètres proxy utilisateur). Les services et composants en arrière‑plan utilisent souvent WinHTTP (paramètres proxy machine). Si ces contextes divergent, vous avez une connectivité en double tête.
9) Dois‑je désactiver IPv6 pour « réparer » les choses ?
Presque jamais comme première réponse. Désactiver IPv6 peut masquer des problèmes réels de DNS/routage et casser des fonctionnalités Windows modernes et certains comportements VPN. Si vous suspectez IPv6, testez explicitement (résolution AAAA, ping/traceroute IPv6) plutôt que de le supprimer.
10) Comment rendre la réinitialisation réversible en pratique ?
En exportant l’état avant changements : configuration d’interface, routes (y compris persistantes), adresses serveurs DNS, et paramètres proxy. Si la machine utilise des adresses statiques ou des routes spéciales, notez‑les comme si elles comptaient—parce que c’est le cas.
Conclusion: next steps that don’t create new tickets
Si vous retenez une chose : réinitialiser la pile réseau n’est pas du dépannage ; c’est une étape de remédiation. Utilisez‑la quand vous avez resserré le problème sur une corruption locale ou un mauvais état—pas quand vous vous ennuyez.
Faites ceci ensuite, dans l’ordre :
- Exécutez le plan de diagnostic rapide : interface → passerelle → IP externe → DNS → proxy/VPN → filtrage.
- Capturez l’état vers
C:\Temp\net-reset(ou l’endroit attendu par votre organisation). Traitez‑le comme des preuves d’incident. - Essayez d’abord les réinitialisations douces : redémarrage d’adaptateur, renouvellement DHCP, vidage DNS, reset proxy (diagnostique), redémarrage de Dnscache.
- Si encore cassé et que vous avez une fenêtre de reboot : Winsock reset + TCP/IP reset, puis un seul reboot—proprement.
- Après toute réinitialisation : vérifiez les routes et les routes persistantes, confirmez les serveurs DNS, confirmez l’intention du proxy, puis retestez l’application qui échouait initialement.
Surtout : si la « réinitialisation » est la réparation, notez pourquoi elle a aidé. Si vous ne pouvez pas l’expliquer, vous n’avez pas réparé le système—vous avez juste négocié avec lui.