O resetare de rețea în Windows șterge mai mult decât defecțiunea VPN

Sfatul apare în zece minute după fiecare reclamație VPN din Windows: rulează resetarea de rețea, rezolvă tot. Nu rezolvă, și nu este îngustă. Butonul respectiv curăță adaptoare, reconectează protocoale, elimină adrese statice și rute implicite, aruncă intrări de firewall și filtre și uită profilele Wi-Fi pe deasupra. Pe un calculator cu un tunel funcțional dar configurat greșit, transformă o defecțiune diagnosticabilă într-o reconstrucție nedocumentată. Salvați mai întâi cinci lucruri și păstrați opțiunea de a anula.

Resetarea nu se limitează la profilul VPN

O conexiune VPN este un obiect printre multe care împart stiva de rețea. Eliminarea și readăugarea unui adaptor schimbă indexul interfeței, iar orice făcea referire la acel index, de la o rută la o regulă de firewall la un driver de filtru terț, se referă acum la ceva ce nu mai există.

Virtualizarea înrăutățește situația. Comutatoarele Hyper-V, podurile VMware, rețelele de containere și clienții VPN cu adaptoare virtuale proprii trăiesc toate în același spațiu. O resetare care reinstalează stiva de bază poate lăsa acele componente pe jumătate prezente, iar calculatorul rezultat raportează hardware funcțional fără nicio cale funcțională.

Nimic din toate acestea nu este un argument împotriva resetării vreodată. Este un argument împotriva resetării mai întâi, pe un calculator pe care nu l-ați documentat, când defecțiunea reală ar putea fi o singură intrare de rută sau un singur filtru învechit. Resetarea este un instrument larg cu o rată de succes îngustă, iar folosirea ei ca primă mișcare garantează că nu veți afla niciodată care dintre cele două a fost.

Salvați dovezile înainte de a salva setările

Defecțiunea în sine este dată. Notați codul exact de eroare, ora, ce profil a fost selectat și dacă gateway-ul a înregistrat măcar o încercare. Un cod care spune că tunelul nu a primit niciodată un răspuns și un cod care spune că autentificarea a eșuat indică reparații complet diferite. După o resetare s-ar putea să nu puteți reproduce niciunul. Tratați starea defectă ca pe un activ pe care sunteți pe punctul de a-l cheltui.

Capturați starea cât încă este defectă, într-un folder din afara directoarelor temporare ale calculatorului:

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

Ultima comandă este cea pe care oamenii o omit, și este adesea cea care explică defecțiunea. Filtrele rămase de la un client eliminat supraviețuiesc ca politică persistentă, iar XML-ul exportat este singura înregistrare locală a acestora. Citiți-l înainte ca o resetare să șteargă lucrul pe care încercați să îl identificați.

Salvați configurația care nu va reveni

Unele setări sunt recreate automat. Adresele statice, rutele personalizate, sufixele DNS, excepțiile de proxy și regulile de firewall nu. Nici profilele în sine, care trăiesc într-un fișier de carte de telefon pe care resetarea nu îl restaurează pentru dumneavoastră.

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

Lista de certificate contează mai mult decât pare. Certificatele de client nu sunt distruse de o resetare de rețea, dar lista vă spune de care depindea profilul și dacă vreunul expiră curând. Descoperirea unui certificat expirat după o reconstrucție irosește reconstrucția.

Scrieți calea de recuperare înainte de a începe

Dacă aparatul este la distanță și VPN-ul este singura cale de intrare, resetarea poate încheia sesiunea și s-ar putea să nu existe cale de întoarcere fără cineva la fața locului. Confirmați că există acces în afara benzii sau că o persoană este disponibilă înainte de a rula orice atinge adaptoare.

Păstrați instalatoarele și detaliile de conectare undeva unde calculatorul le mai poate accesa ulterior. Un client care trebuie reinstalat dintr-un portal de furnizor accesat prin tunel este o dependență circulară, și este cel mai frecvent mod în care această procedură devine o întrerupere.

Apoi notați ce faceți și de ce, inclusiv comenzile exacte. Următoarea persoană trebuie să știe dacă resetarea a fost un experiment sau o decizie, iar „am încercat tot” nu este o înregistrare.

Testați pe straturi după resetare

Restaurarea prea multor lucruri deodată face rezultatul ilizibil. Lucrați de jos: adaptor și adresă, apoi rezolvarea numelor, apoi etapa de identitate a tunelului, apoi aplicația. Fiecare strat are o comandă care răspunde la propria întrebare:

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

Dacă stratul adaptorului este sănătos și rezolvarea nu, opriți-vă și reparați rezolvarea. Reinstalarea clientului VPN în acel moment adaugă o variabilă și elimină un indiciu. Restaurați doar setările pe care le puteți explica, una câte una, verificând același strat după fiecare.

Ghidul propriu de depanare al Microsoft pentru eroarea 720, de exemplu, distinge problemele de legare de problemele de alocare a adreselor în loc să prescrie o resetare generală, ceea ce este instinctul corect pentru fiecare cod din această familie. Citiți ce afirmă codul înainte de a apela la cel mai larg instrument disponibil.