Nėra interneto pašalinus VPN: inventorizacija prieš atkūrimą

Pašalinus VPN klientą kompiuteris turėtų grįžti į būseną prieš jį, o kartais grąžinamas kompiuteris, kuriame niekas neišsprendžiama ir naršyklė vis dar nori tarpinio serverio. Likučiai ateina iš trumpo savininkų sąrašo: maršrutai, Winsock tiekėjai, tarpinio serverio nustatymas, DNS ir filtro tvarkyklės. Yra dvi taisymo strategijos, ir jos daugiausia skiriasi tuo, ką sunaikina.

Du taisymai labai skirtingomis sąnaudomis

Platus atkūrimas nėra klaida; jis brangus. Jis taip pat pašalina įrodymus, kurie pasakytų, kuris sluoksnis nepavyko, todėl kitas kompiuteris su tuo pačiu simptomu vėl pradeda nuo nulio. Inventorizacija iš pradžių kainuoja keturias komandas, ir trys iš jų tik skaito.

Rinkitės pagal laikrodį, o ne pagal pageidavimą. Kompiuteryje, kuris turi veikti po dešimties minučių, visas atkūrimas gali būti teisingas sprendimas, o pastaba, kurią paliksite vėliau, yra vienintelis dalykas, saugantis žinias. Parke su pasikartojančiu simptomu inventorizacija yra pigesnis kelias, nes ji duoda priežastį, o ne pasibaigusį trikdį.

Perskaitykite keturis dalykus prieš ką nors liesdami

ipconfig /all
route print -4
netsh winsock show catalog
netsh winhttp show proxy

Kiekviena išvestis atitinka skirtingą gedimą. Numatytasis maršrutas, rodantis į adapterį, kurio nebėra, paaiškina mirusį internetą veikiant vietiniam tinklui. Adapterio DNS serveris, kadaise priklausęs tuneliui, paaiškina vardus, kurie nepavyksta, kol adresai veikia. Kliento įdiegtas Winsock tiekėjas paaiškina naršyklės gedimus, kurie išgyvena kiekvieną maršruto pakeitimą. Tarpinio serverio įrašas paaiškina naršyklę, kuri nieko nepasiekia, kol curl pasiekia.

Atskirai patikrinkite paties naršyklės tarpinį serverį. Jis gyvena interneto parinkčių dialoge, skyriuje apie ryšius ir vietinio tinklo nustatymus, ir tai kitas nustatymas nei komandos pranešamas WinHTTP tarpinis serveris. Sutaisius vieną nesutaisomas kitas, ir kompiuteris gali turėti abu. Ieškokite tarpinio serverio adreso, kuris niekur neišsprendžiamas, nes tokią formą palieka pašalintas klientas.

Lipkite laiptais, o ne šokite

ipconfig /release
ipconfig /renew
ipconfig /flushdns
route -f
netsh int ip reset reset.log
netsh winsock reset catalog

route -f išvalo maršruto lentelę neliesdamas adapterių, o tai pigiausias būdas pašalinti likusį numatytąjį tunelio maršrutą. netsh int ip reset perrašo TCP/IP krūvos nustatymus ir tikisi paleidimo iš naujo. netsh winsock reset atkuria katalogą, kurį pakeitė filtro tvarkyklė, ir būtent šis žingsnis ištaiso gedimus, matomus tik naršyklėje. Paleiskite vieną, išbandykite, tada paleiskite kitą; laiptai, kuriais užlipote, yra laiptai, kuriuos vėliau galite aprašyti.

netsh advfirewall reset nėra šių laiptų dalis. Jis ištrina taisykles, kurias kas nors sukūrė sąmoningai, ir jų atkūrimas yra atskiras projektas. Nustatymų programos tinklo atkūrimas pašalina ir iš naujo įdiegia kiekvieną adapterį, taip pat ištrina išsaugotus Wi-Fi slaptažodžius, todėl jis eina po siaurų žingsnių, o ne prieš juos.

Likučiai, kurių savininkas yra kitas produktas

Vilkdami programą į šiukšliadėžę jos nepašalinsite. Mac, kuris toliau naudojo VPN, kurio nebebrėžė, vis dar turėjo veikiantį tiekėjo pagalbinį įrankį; Activity Monitor tinklo skirtukas jį atpažino pagal srautą, o tiekėjo šalinimo procedūra pašalino demoną ir jo paleidimo elementus. Patikrinkite /Library/LaunchDaemons ir /Library/LaunchAgents įrašus, kurių programa nebeegzistuoja.

Saugumo programinė įranga yra kita vieta, kur pasireiškia šis modelis. Antivirusinės priemonės įdiegia savo filtro tvarkykles, o šalinimas, paliekantis vieną, gali sugadinti VPN adapterį taip, kad joks VPN nustatymas to nepaaiškins. Tiekėjo šalinimo įrankis egzistuoja būtent tokiam atvejui; įprastas šalinimas dažniausiai jo nepasiekia.

Diegimo programos taip pat gali atsisakyti pradėti, nes ankstesnis egzempliorius dar gyvas. OpenVPN diegimo programa tikrina, ar veikia openvpn.exe, įskaitant tą, kurį jūsų pačių scenarijus paleido prieš kelias valandas.

env_block gedimas yra kitos rūšies likutis. PATH prarado C:\Windows\System32 ir jo kaimynus, todėl klientas negali paleisti paslaugų, kurios sukuria adapterį. Taisykite PATH, o ne diegkite iš naujo, nes nauja kopija susidurs su tais pačiais trūkstamais komandomis.

Linux sąsajos ir maršrutizatoriaus testas

tun sąsaja gali pergyventi ją sukūrusią konfigūraciją. Viena lėto atsisiuntimo ataskaita baigėsi likutiniu įrenginiu, kuris laikė senosios grupės šliuzo adresą ir traukė srautą į tunelį, kurio niekas neketino. ip -brief link išvardija, kas egzistuoja; palyginkite tai su tuo, ką teigia dabartinė paslauga, tada ištrinkite našlaitį.

Nuomos, kurios nustoja ateiti po VPN eksperimento, nėra automatiškai krūvos problema. Išbandykite nešiojamąjį kompiuterį, kuris niekada nenešė kliento, ir kitą maršrutizatorių prieš paleisdami daugiau atkūrimų. Jei maršrutizatorius nustojo atsakyti, jokia Windows komanda to nepakeis, o laikinas statinis adresas, šliuzas ir sprendėjas pasako, kuri pusė sugedusi.

Užrašykite, ką atkūrėte ir kokia tvarka. Kitas žmogus turi žinoti, ar Winsock katalogas, ar ugniasienė buvo atstatyti, ir ta pastaba yra vienintelis dalykas, kurio šalinimas negali pasiimti.