Nėra interneto pašalinus VPN? Patikrinkite tris savininkus

Klientas dingo, o kompiuteris vis dar nieko nepasiekia, todėl kyla pagunda išlyginti užkardą ir pradėti iš naujo. Nedarykite to. Blokavimo būsena gali kilti iš trijų skirtingų savininkų tame pačiame kompiuteryje, ir kiekvienas turi savo pašalinimo kelią. Visko iš karto išplovimas pašalina objektą, kurio norėjote atsikratyti, kartu su apsauga, kurios dar reikia, ir taip pat sunaikina įrodymą, kuris savininkas sukėlė problemą. Penki patikrinimai, iš eilės, to neleidžia.

Patikrinimas 1: kas dar liko ir kam tai skirta

Ieškokite trijų artefaktų atskirai: virtualaus adapterio, kuris dar egzistuoja, užkardos filtro ar taisyklės, kuri dar blokuoja, ir maršruto ar politikos taisyklės, kuri dar rodo į tunelį, kurio nebėra. Jų buvimas pats savaime nieko neįrodo, nes tyčia įtaisytas avarinis jungiklis iš išorės atrodo taip pat kaip apleistas.

Get-NetAdapter | Where-Object Status -eq 'Up'
Get-NetFirewallRule -Enabled True -Direction Outbound | Where-Object Action -eq 'Block'
ip route show
ip -4 rule show

Užsirašykite laiką, kada nutrūko ryšys, ir ar įprastas klientas dar gali paleisti savo tunelį. Jei klientas gali atkurti tunelį ir srautas grįžta, blokavimas atlieka savo darbą, o problema yra kliento būsenoje, o ne likusioje taisyklėje.

Patikrinimas 2: kuris savininkas tai kontroliuoja

Kiekvienas artefaktas turi savininką. Virtualus adapteris priklauso VPN klientui arba jo tvarkyklei. Filtras gali priklausyti klientui, pačios platformos užkardai arba valdomam saugumo produktui. Maršrutą klientas galėjo įdiegti jungdamasis ir palikti.

Valdomoje įrangoje patikrinkite įrenginio politiką prieš ką nors liesdami. Politikos primestas filtras bus atkurtas kito prisijungimo metu, todėl vietinis pašalinimas nuperka valandą ir atitikties ataskaitą. Tas pokalbis priklauso administratoriui, o ne užkardos sąsajai.

Patikrinimas 3: pašalinkite siauriausią dalyką, kuris tai paaiškina

Pradėkite nuo tiekėjo palaikomo kelio: taisymo diegimas ar tinkamas šalinimas dažnai teisingai sutvarko sugeneruotą būseną, įskaitant filtrus, kuriuos rankinis šalinimas praleistų. Perskaitykite įdiegtos versijos atkūrimo instrukcijas, nes tvarka svarbi ir šalinimas po nepavykusio šalinimo elgiasi kitaip.

Jei rankinė patikra tikrai reikalinga, prieš ką nors keisdami užrašykite taisyklės pavadinimą, sąsają ir nurodytą tikslą, ir pašalinkite tą objektą pagal pavadinimą. Šalinti kiekvieną tinklo adapterį ar išplauti visą taisyklių rinkinį, siekiant vieno kliento, yra kelias, kuriuo palaikymo atvejis tampa perstatymu.

Patikrinimas 4: DNS ir maršrutai pergyvena adapterius

Sprendimo būsena gali pergyventi tunelį. Sprendėjas, kuris dar rodo į adresą tunelio viduje, kurio nebėra, sukuria laiko limitus, kurie atrodo būtent kaip užkardos numetimas, ir įprasta išvada yra neteisinga.

resolvectl status
ip route get 1.1.1.1
nslookup example.com

Jei adresas išsprendžiamas ir neapdorotas ryšys per IP veikia, DNS yra likusi problema, o ne filtravimas. Jei abu nepavyksta, grįžkite prie pirmo patikrinimo su maršrutu ir filtru rankose.

Patikrinimas 5: dar kartą patikrinkite abu kelius ir grąžinkite diagnostiką

Pirmiausia patikrinkite įprastą ryšį, tada kiekvieną likusį VPN profilį per jo paties valdiklius: prisijunkite, naudokite, atsijunkite ir patvirtinkite, kad priegloba grįžo prie paprasto ryšio. Tas ratas yra testas, įrodantis, kad apleistas blokavimas dingo, o ne buvo tik apėjęs.

Galiausiai atkurkite bet kokį diagnostinį pakeitimą, kurį padarėte kelyje. Sėkmingas valymas pašalina vieną apleistą priklausomybę; jis nepašalina bendros prieglobos apsaugos ir neturėtų palikti visam laikui atlaisvintos užkardos. Atsižvelkite, kuris savininkas laikė blokavimą, nes kitas šalinimas duos tuos pačius tris kandidatus.