Reset sieci w Windows usuwa więcej niż tylko awarię VPN
Reset czyści adaptery, trasy i filtry WFP, nie tylko niedziałający tunel. Najpierw zapisz profil, listę certyfikatów i dowody, a potem testuj warstwami.
Rada przychodzi w ciągu dziesięciu minut po każdej skardze na VPN w Windows: uruchom reset sieci, naprawi wszystko. Nie naprawi, i nie jest wąski. Ten przycisk czyści adaptery, ponownie wiąże protokoły, usuwa adresy statyczne i trasy domyślne, wyrzuca wpisy zapory i filtrów, a na dokładkę zapomina profile Wi-Fi. Na maszynie z działającym, ale źle skonfigurowanym tunelem zamienia jedną diagnozowalną usterkę w nieudokumentowaną przebudowę. Zapisz najpierw pięć rzeczy, a zachowasz możliwość cofnięcia tego.
Reset nie jest ograniczony do profilu VPN
Połączenie VPN to jeden obiekt wśród wielu współdzielących stos sieciowy. Usunięcie i ponowne dodanie adaptera zmienia indeks interfejsu, a wszystko, co odwoływało się do tego indeksu, od trasy przez regułę zapory po sterownik filtra firmy trzeciej, odnosi się teraz do czegoś, czego już nie ma.
Wirtualizacja to pogarsza. Przełączniki Hyper-V, mosty VMware, sieci kontenerów i klienci VPN z własnymi wirtualnymi adapterami żyją w tej samej przestrzeni. Reset, który reinstaluje podstawowy stos, może zostawić te komponenty w połowie obecne, a powstała maszyna zgłasza działający sprzęt bez działającej ścieżki.
Nic z tego nie jest argumentem przeciwko kiedykolwiek resetowaniu. To argument przeciwko resetowaniu najpierw, na maszynie, której nie udokumentowano, gdy rzeczywista usterka może być jednym wpisem trasy albo jednym przestarzałym filtrem. Reset to szerokie narzędzie o wąskiej skuteczności, a użycie go jako pierwszego ruchu gwarantuje, że nigdy nie dowiesz się, które z tych dwóch to było.
Zapisz dowody, zanim zapiszesz ustawienia
Sama awaria jest danymi. Zanotuj dokładny kod błędu, czas, który profil był wybrany i czy brama w ogóle zapisała próbę. Kod mówiący, że tunel nigdy nie dostał odpowiedzi, i kod mówiący, że uwierzytelnianie się nie powiodło, wskazują na zupełnie różne naprawy. Po resecie możesz nie być w stanie odtworzyć żadnego z nich. Traktuj zepsuty stan jako zasób, który zaraz wydasz.
Przechwyć stan, póki jest jeszcze zepsuty, do folderu poza katalogami tymczasowymi maszyny:
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.xmlOstatnie polecenie jest tym, które ludzie pomijają, i często właśnie ono wyjaśnia usterkę. Pozostałe filtry usuniętego klienta przetrwają jako trwała zasada, a wyeksportowany XML jest jedynym lokalnym zapisem o nich. Przeczytaj go, zanim reset usunie to, co próbowałeś zidentyfikować.
Zapisz konfigurację, która nie wróci
Niektóre ustawienia są odtwarzane automatycznie. Adresy statyczne, trasy niestandardowe, sufiksy DNS, wyjątki serwera proxy i reguły zapory nie. Same profile też nie, które żyją w pliku książki telefonicznej, którego reset za ciebie nie przywróci.
| 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,NotAfterLista certyfikatów ma większe znaczenie, niż wygląda. Reset sieci nie niszczy certyfikatów klienta, ale lista mówi ci, od których zależał profil i czy któryś wkrótce wygaśnie. Odkrycie wygasłego certyfikatu po przebudowie marnuje przebudowę.
Zapisz ścieżkę odzyskiwania, zanim zaczniesz
Jeśli maszyna jest zdalna, a VPN to jedyne wejście, reset może zakończyć twoją sesję i może nie być drogi powrotu bez kogoś na miejscu. Potwierdź, że istnieje dostęp poza pasmem lub że jest dostępna osoba, zanim uruchomisz cokolwiek, co dotyka adapterów.
Przechowuj instalatory i dane połączenia tam, gdzie maszyna będzie mogła do nich dotrzeć później. Klient, którego trzeba ponownie zainstalować z portalu dostawcy dostępnego przez tunel, to zależność cykliczna, i to najczęstszy sposób, w jaki ta procedura staje się awarią usługi.
Potem zapisz, co robisz i dlaczego, wraz z dokładnymi poleceniami. Następna osoba musi wiedzieć, czy reset był eksperymentem, czy decyzją, a „próbowaliśmy wszystkiego” nie jest zapisem.
Testuj warstwami po resecie
Przywrócenie zbyt wielu rzeczy naraz czyni wynik nieczytelnym. Pracuj od dołu: adapter i adres, potem rozwiązywanie nazw, potem etap tożsamości tunelu, potem aplikacja. Każda warstwa ma polecenie, które odpowiada na jej własne pytanie:
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 443Jeśli warstwa adaptera jest zdrowa, a rozwiązywanie nazw nie, zatrzymaj się i napraw rozwiązywanie. Ponowna instalacja klienta VPN w tym momencie dodaje zmienną i usuwa wskazówkę. Przywracaj tylko ustawienia, które potrafisz wyjaśnić, po jednym, sprawdzając tę samą warstwę po każdym.
Własne wskazówki firmy Microsoft dotyczące rozwiązywania problemów z błędem 720 na przykład odróżniają problemy z wiązaniem od problemów z przydzielaniem adresów, zamiast zalecać ogólny reset, co jest właściwym odruchem dla każdego kodu w tej rodzinie. Przeczytaj, co twierdzi kod, zanim sięgniesz po najszersze dostępne narzędzie.