Ingen internett etter avinstallering av VPN? Sjekk tre eigarar

Klienten er borte og maskinen når framleis ingen ting, noko som freistar til å jamne ut brannmuren og byrje på nytt. Ikkje gjer det. Blokkerande tilstand kan kome frå tre ulike eigarar på same maskin, og kvar har sin eigen fjerningsveg. Å skylje alt på ein gong fjernar objektet du ville bli kvitt, saman med vernet du framleis treng, og det øydelegg òg beviset for kva eigar som førte til problemet. Fem kontrollar, i rekkjefølgje, hindrar det.

Kontroll 1: kva er framleis der, og kva er det for

Sjå etter dei tre artefaktane kvar for seg: ein virtuell adapter som framleis finst, eit brannmurfilter eller ei regel som framleis blokkerer, og ei rute eller ei policyregel som framleis peikar mot ein tunnel som ikkje lenger finst. Tilstadevera deira beviser ingenting i seg sjølv, fordi ein medviten naudstoppar ser utanfrå lik ut som ein forlaten.

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

Skriv ned tidspunktet då tilkoplinga stoppa, og om den vanlege klienten framleis kan starte tunnelen sin. Viss klienten kan gjenopprette tunnelen og trafikken kjem tilbake, gjer blokkeringa jobben sin, og problemet er tilstanden til klienten, ikkje ei attverande regel.

Kontroll 2: kva eigar som kontrollerer det

Kvar artefakt har ein eigar. Den virtuelle adapteren høyrer til VPN-klienten eller drivaren hans. Filteret kan høyre til klienten, til brannmuren til plattforma sjølv eller til eit administrert tryggingsprodukt. Ruta kan ha vorte installert av klienten ved tilkopling og late att.

På administrert utstyr, sjekk einingarpolicyen før du rører noko. Eit filter som blir handheva av policy, blir gjenoppretta ved neste innsjekk, så ein lokal fjerning kjøper ein time og ein samsvarsrapport. Den samtalen høyrer til administratoren, ikkje til grensesnittet til brannmuren.

Kontroll 3: fjern det smalaste som forklarer det

Start med den støtta vegen til leverandøren: ein reparasjonsinstallasjon eller ein ordentleg avinstallering ryddar ofte opp i generert tilstand på rett måte, inkludert filter som ein manuell fjerning ville oversjå. Les gjenopprettingsinstruksjonane for den installerte versjonen, fordi rekkjefølgja har noko å seie, og ein avinstallering etter ein mislukka fjerning oppfører seg annleis.

Viss manuell inspeksjon verkeleg er naudsynt, noter regelnavnet, grensesnittet og det oppgitte føremålet før du endrar noko, og fjern det objektet ved namn. Å fjerne kvar nettverksadapter eller skylje heile regelsettet for å treffe éin klient er måten ein støttesak blir ein gjenoppbygging.

Kontroll 4: DNS og ruter overlever adapterar

Oppløysingstilstand kan overleve tunnelen. Ein resolver som framleis peikar på ei adresse inne i ein tunnel som ikkje lenger finst, produserer tidsavbrot som ser nøyaktig ut som eit brannmurfunn, og den vanlege konklusjonen er den feil.

resolvectl status
ip route get 1.1.1.1
nslookup example.com

Viss adressa blir løyst opp og ei rå tilkopling via IP fungerer, er DNS det attverande problemet og ikkje filtrering. Viss begge feilar, gå tilbake til kontroll éin med ruta og filteret i handa.

Kontroll 5: test begge vegar på nytt og set diagnostikken tilbake

Stadfest vanleg tilkopling først, deretter kvar attverande VPN-profil gjennom sine eigne kontrollar: kople til, bruk han, kople frå, og stadfest at verten er tilbake til vanleg tilkopling. Den rundturen er testen som beviser at den forlatne blokkeringa er borte og ikkje berre omgått.

Til slutt, gjenopprett kvar diagnostisk endring du gjorde undervegs. Ein vellukka opprydding fjernar éin forlaten avhengnad; ho fjernar ikkje det generelle vernet til verten, og ho bør ikkje etterlate ein permanent svekt brannmur. Noter kva eigar som heldt blokkeringa, fordi neste avinstallering vil gje dei same tre kandidatane.