Un restabliment de xarxa de Windows esborra més que la fallada de la VPN

El consell arriba als deu minuts de cada queixa de VPN a Windows: executa el restabliment de xarxa, ho arregla tot. No ho fa, i no és estret. Aquest botó neteja adaptadors, torna a enllaçar protocols, elimina adreces estàtiques i rutes per defecte, descarta entrades de tallafocs i filtres, i encara oblida perfils Wi-Fi per acabar-ho d'arrodonir. En una màquina amb un túnel que funciona però està mal configurat, converteix una fallada diagnosticable en una reconstrucció no documentada. Deseu primer cinc coses i conservareu l'opció de desfer-ho.

El restabliment no es limita al perfil de la VPN

Una connexió VPN és un objecte entre molts que comparteixen la pila de xarxa. Treure i tornar a afegir un adaptador canvia l'índex de la interfície, i qualsevol cosa que feia referència a aquest índex, des d'una ruta fins a una regla de tallafocs fins a un controlador de filtre de tercers, ara fa referència a una cosa que ja no existeix.

La virtualització ho empitjora. Els commutadors Hyper-V, els ponts de VMware, les xarxes de contenidors i els clients VPN amb adaptadors virtuals propis viuen tots al mateix espai. Un restabliment que reinstal·la la pila base pot deixar aquests components mig presents, i la màquina resultant informa de maquinari que funciona sense cap camí que funcioni.

Res d'això no és un argument contra restablir mai. És un argument contra restablir primer, en una màquina que no heu documentat, quan la fallada real pot ser una entrada de ruta o un filtre obsolet. Un restabliment és una eina àmplia amb una taxa d'èxit estreta, i fer-lo servir com a primera jugada garanteix que mai sabreu quina de les dues coses era.

Deseu les evidències abans de desar la configuració

La fallada en si és una dada. Anoteu el codi d'error exacte, l'hora, quin perfil estava seleccionat i si la passarel·la va registrar algun intent. Un codi que diu que el túnel no va rebre mai resposta i un codi que diu que l'autenticació va fallar assenyalen reparacions completament diferents. Després d'un restabliment potser no podreu reproduir ni una ni l'altra. Tracteu l'estat trencat com un actiu que esteu a punt de gastar.

Captureu l'estat mentre encara està trencat, en una carpeta fora dels directoris temporals de la màquina:

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

L'última ordre és la que la gent omet, i sovint és la que explica la fallada. Els filtres sobrants d'un client eliminat sobreviuen com a política persistent, i el XML exportat és l'únic registre local que en queda. Llegiu-lo abans que un restabliment esborri allò que intentàveu identificar.

Deseu la configuració que no tornarà

Algunes opcions es tornen a crear automàticament. Les adreces estàtiques, les rutes personalitzades, els sufixos DNS, les excepcions de servidor intermediari i les regles de tallafocs, no. Els perfils mateixos tampoc, que viuen en un fitxer de llibreta de telèfons que el restabliment no us restaura.

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 llista de certificats importa més del que sembla. Els certificats de client no es destrueixen amb un restabliment de xarxa, però la llista us diu de quins depenia el perfil i si algun caduca aviat. Descobrir un certificat caducat després d'una reconstrucció malgasta la reconstrucció.

Escriviu el camí de recuperació abans de començar

Si la màquina és remota i la VPN és la vostra única via d'entrada, el restabliment pot acabar la sessió i potser no hi ha manera de tornar sense algú allà. Confirmeu que existeix accés fora de banda, o que hi ha una persona disponible, abans d'executar res que toqui adaptadors.

Guardeu els instal·ladors i les dades de connexió en un lloc on la màquina encara hi pugui arribar després. Un client que s'ha de reinstal·lar des d'un portal de proveïdor al qual s'arriba pel túnel és una dependència circular, i és la manera més comuna que aquest procediment es converteixi en una caiguda de servei.

A continuació, registreu què feu i per què, incloent-hi les ordres exactes. La persona següent ha de saber si el restabliment va ser un experiment o una decisió, i “ho hem provat tot” no és cap registre.

Proveu per capes després del restabliment

Restaurar massa coses alhora fa que el resultat no es pugui llegir. Treballeu des de baix: adaptador i adreça, després resolució de noms, després l'etapa d'identitat del túnel, després l'aplicació. Cada capa té una ordre que respon a la seva pròpia pregunta:

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 capa de l'adaptador està sana i la resolució no, atureu-vos i arregleu la resolució. Reinstal·lar el client VPN en aquest moment afegeix una variable i elimina una pista. Restaureu només les opcions que podeu explicar, una a la vegada, comprovant la mateixa capa després de cadascuna.

La guia de resolució de problemes de Microsoft per a l'error 720, per exemple, distingeix problemes d'enllaç de problemes d'assignació d'adreces en lloc de prescriure un restabliment general, que és l'instint correcte per a cada codi d'aquesta família. Llegiu què afirma el codi abans d'agafar l'eina més àmplia disponible.