En nätverksåterställning i Windows raderar mer än VPN-felet

Rådet kommer inom tio minuter efter varje Windows-VPN-klagomål: kör nätverksåterställningen, den fixar allt. Det gör den inte, och den är inte smal. Knappen rensar adaptrar, binder om protokoll, tar bort statiska adresser och standardrutter, slänger brandväggs- och filterposter och glömmer dessutom Wi-Fi-profiler. På en maskin med en tunnel som fungerar men är felkonfigurerad förvandlar den ett diagnostiserbart fel till en odokumenterad ombyggnad. Spara fem saker först, så behåller du möjligheten att ångra det.

Återställningen är inte begränsad till VPN-profilen

En VPN-anslutning är ett objekt bland många som delar nätverksstacken. Att ta bort och lägga till en adapter igen ändrar gränssnittsindexet, och allt som refererade till det indexet, från en rutt till en brandväggsregel till en tredjeparts filterdrivrutin, refererar nu till något som inte längre finns.

Virtualisering gör det värre. Hyper-V-växlar, VMware-bryggor, containernätverk och VPN-klienter med egna virtuella adaptrar lever alla i samma utrymme. En återställning som installerar om basstacken kan lämna de komponenterna halvt närvarande, och den resulterande maskinen rapporterar fungerande hårdvara utan en fungerande väg.

Inget av det är ett argument mot att någonsin återställa. Det är ett argument mot att återställa först, på en maskin du inte har dokumenterat, när det faktiska felet kanske är en enda ruttpost eller ett enda föråldrat filter. En återställning är ett brett verktyg med en smal framgångsfrekvens, och att använda den som första drag garanterar att du aldrig får veta vilket av de två det var.

Spara bevisen innan du sparar inställningarna

Själva felet är data. Notera den exakta felkoden, tiden, vilken profil som var vald och om gatewayen överhuvudtaget loggade ett försök. En kod som säger att tunneln aldrig fick något svar och en kod som säger att autentiseringen misslyckades pekar på helt olika reparationer. Efter en återställning kanske du inte kan återskapa någon av dem. Behandla det trasiga tillståndet som en tillgång du är på väg att spendera.

Fånga tillståndet medan det fortfarande är trasigt, i en mapp utanför maskinens tillfälliga kataloger:

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

Det sista kommandot är det folk utelämnar, och det är ofta det som förklarar felet. Kvarvarande filter från en borttagen klient överlever som beständig policy, och den exporterade XML-filen är den enda lokala registreringen av dem. Läs den innan en återställning raderar det du försökte identifiera.

Spara konfigurationen som inte kommer tillbaka

Vissa inställningar återskapas automatiskt. Statiska adresser, anpassade rutter, DNS-suffix, proxyundantag och brandväggsregler gör det inte. Inte heller profilerna själva, som ligger i en telefonboksfil som återställningen inte återställer åt dig.

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

Certifikatlistan betyder mer än den ser ut som. Klientcertifikat förstörs inte av en nätverksåterställning, men listan berättar vilka profilen var beroende av och om något löper ut snart. Att upptäcka ett utgånget certifikat efter en ombyggnad slösar bort ombyggnaden.

Skriv ned återställningsvägen innan du börjar

Om maskinen är fjärrstyrd och VPN är din enda väg in kan återställningen avsluta din session och det finns kanske ingen väg tillbaka utan någon på plats. Bekräfta att åtkomst utanför bandet finns, eller att en person är tillgänglig, innan du kör något som rör adaptrar.

Förvara installationsprogrammen och anslutningsuppgifterna någonstans där maskinen fortfarande kan nå dem efteråt. En klient som måste installeras om från en leverantörsportal som nås via tunneln är ett cirkulärt beroende, och det är det vanligaste sättet den här proceduren blir ett avbrott.

Skriv sedan ned vad du gör och varför, inklusive de exakta kommandona. Nästa person måste veta om återställningen var ett experiment eller ett beslut, och ”vi provade allt” är ingen registrering.

Testa i lager efter återställningen

Att återställa för mycket på en gång gör resultatet oläsligt. Arbeta nedifrån: adapter och adress, sedan namnmatchning, sedan tunnelns identitetssteg, sedan programmet. Varje lager har ett kommando som svarar på sin egen fråga:

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

Om adapterlagret är friskt och matchningen inte är det, stanna och rätta matchningen. Att installera om VPN-klienten i det läget lägger till en variabel och tar bort en ledtråd. Återställ bara de inställningar du kan förklara, en i taget, och kontrollera samma lager efter varje.

Microsofts egen felsökningsvägledning för fel 720 skiljer till exempel bindningsproblem från adresstilldelningsproblem i stället för att ordinera en generell återställning, vilket är rätt instinkt för varje kod i den här familjen. Läs vad koden påstår innan du griper efter det bredaste tillgängliga verktyget.