Une réinitialisation réseau Windows efface plus que la panne VPN
Une réinitialisation vide les adaptateurs, les routes et les filtres WFP, pas seulement le tunnel défaillant. Sauvegardez le profil, la liste des certificats et les preuves, puis testez par couches.
Le conseil arrive dans les dix minutes qui suivent chaque plainte VPN sous Windows : lancez la réinitialisation réseau, ça corrige tout. Elle ne corrige pas tout, et elle n'est pas ciblée. Ce bouton vide les adaptateurs, relie de nouveau les protocoles, supprime les adresses statiques et les routes par défaut, jette les entrées de pare-feu et de filtres, et oublie en prime les profils Wi-Fi. Sur une machine dont le tunnel fonctionne mais est mal configuré, il transforme une panne diagnosticable en reconstruction non documentée. Sauvegardez d'abord cinq choses, et vous gardez la possibilité d'annuler.
La réinitialisation ne se limite pas au profil VPN
Une connexion VPN est un objet parmi beaucoup d'autres qui partagent la pile réseau. Retirer puis rajouter un adaptateur change l'index d'interface, et tout ce qui référençait cet index, d'une route à une règle de pare-feu en passant par un pilote de filtre tiers, référence désormais quelque chose qui n'existe plus.
La virtualisation aggrave les choses. Les commutateurs Hyper-V, les ponts VMware, les réseaux de conteneurs et les clients VPN dotés de leurs propres adaptateurs virtuels vivent tous dans le même espace. Une réinitialisation qui réinstalle la pile de base peut laisser ces composants à moitié présents, et la machine qui en résulte signale du matériel fonctionnel sans chemin fonctionnel.
Rien de tout cela n'est un argument contre le fait de réinitialiser un jour. C'est un argument contre le fait de réinitialiser d'abord, sur une machine que vous n'avez pas documentée, alors que la panne réelle n'est peut-être qu'une entrée de route ou un filtre obsolète. Une réinitialisation est un outil large avec un taux de réussite étroit, et l'utiliser comme premier geste garantit que vous ne saurez jamais laquelle des deux elle était.
Sauvegardez les preuves avant de sauvegarder les réglages
La panne elle-même est une donnée. Notez le code d'erreur exact, l'heure, quel profil était sélectionné et si la passerelle a journalisé une tentative. Un code qui dit que le tunnel n'a jamais reçu de réponse et un code qui dit que l'authentification a échoué orientent vers des réparations complètement différentes. Après une réinitialisation, vous ne pourrez peut-être reproduire ni l'un ni l'autre. Traitez l'état cassé comme un actif que vous êtes sur le point de dépenser.
Capturez l'état pendant qu'il est encore cassé, dans un dossier hors des répertoires temporaires de la machine :
mkdir C:\vpn-evidence
ipconfig /all > C:\vpn-evidence\ipconfig.txt
route print > C:\vpn-evidence\routes.txt
Get-VpnConnection -AllUserConnection | Export-Csv C:\vpn-evidence\profiles.csv -NoTypeInformation
netsh wfp show state file=C:\vpn-evidence\wfp.xml
La dernière commande est celle que les gens oublient, et c'est souvent celle qui explique la panne. Les filtres résiduels d'un client supprimé survivent comme stratégie persistante, et le XML exporté en est le seul enregistrement local. Lisez-le avant qu'une réinitialisation efface ce que vous cherchiez à identifier.
Sauvegardez la configuration qui ne reviendra pas
Certains réglages sont recréés automatiquement. Les adresses statiques, les routes personnalisées, les suffixes DNS, les exceptions de proxy et les règles de pare-feu ne le sont pas. Les profils eux-mêmes non plus, qui vivent dans un fichier de carnet d'adresses que la réinitialisation ne restaure pas pour vous.
| What to save | Where it lives | Why the reset loses it |
|---|---|---|
| VPN profiles | rasphone.pbk in ProgramData or the user profile | Profiles are not part of the adapter state |
| Static IP and DNS | Adapter configuration | Adapters are removed and recreated |
| Persistent filters | WFP policy store | Filter state is cleared with the stack |
| Third-party bindings | Adapter binding list | Components must be reinstalled manually |
Get-NetIPConfiguration | Out-File C:\vpn-evidence\netip.txt
Get-NetRoute -AddressFamily IPv4 | Export-Csv C:\vpn-evidence\netroutes.csv -NoTypeInformation
Get-DnsClientServerAddress | Export-Csv C:\vpn-evidence\dns.csv -NoTypeInformation
Get-ChildItem Cert:\LocalMachine\My | Select-Object Subject,Thumbprint,NotAfter
La liste des certificats compte plus qu'il n'y paraît. Les certificats clients ne sont pas détruits par une réinitialisation réseau, mais la liste vous dit desquels le profil dépendait et si l'un expire bientôt. Découvrir un certificat expiré après une reconstruction gâche la reconstruction.
Écrivez le chemin de reprise avant de commencer
Si la machine est distante et que le VPN est votre seul accès, la réinitialisation peut mettre fin à votre session et il n'y aura peut-être aucun retour sans quelqu'un sur place. Confirmez qu'un accès hors bande existe, ou qu'une personne est disponible, avant d'exécuter quoi que ce soit qui touche aux adaptateurs.
Stockez les installateurs et les détails de connexion là où la machine peut encore les atteindre ensuite. Un client qu'il faut réinstaller depuis un portail fournisseur joignable via le tunnel est une dépendance circulaire, et c'est la façon la plus courante dont cette procédure devient une panne de service.
Ensuite, notez ce que vous faites et pourquoi, y compris les commandes exactes. La personne suivante doit savoir si la réinitialisation était une expérience ou une décision, et « nous avons tout essayé » n'est pas un enregistrement.
Testez par couches après la réinitialisation
Restaurer trop de choses à la fois rend le résultat illisible. Travaillez par le bas : adaptateur et adresse, puis résolution de noms, puis l'étape d'identité du tunnel, puis l'application. Chaque couche a une commande qui répond à sa propre question :
Get-NetAdapter | Where-Object Status -eq 'Up' | Select-Object Name,InterfaceDescription
Resolve-DnsName intranet.example.internal
Get-VpnConnection -Name 'Corp' | Select-Object ConnectionStatus,TunnelType
Test-NetConnection -ComputerName intranet.example.internal -Port 443
Si la couche adaptateur est saine et que la résolution ne l'est pas, arrêtez-vous et corrigez la résolution. Réinstaller le client VPN à ce stade ajoute une variable et retire un indice. Ne restaurez que les réglages que vous pouvez expliquer, un à la fois, en vérifiant la même couche après chacun.
Les propres conseils de dépannage de Microsoft pour l'erreur 720, par exemple, distinguent les problèmes de liaison des problèmes d'attribution d'adresses au lieu de prescrire une réinitialisation générale, ce qui est le bon réflexe pour chaque code de cette famille. Lisez ce que le code affirme avant de saisir l'outil le plus large disponible.