Ingen internett etter avinstallering av VPN? Sjekk tre eiere

Klienten er borte og maskinen når fortsatt ingenting, noe som frister til å jevne ut brannmuren og begynne på nytt. Ikke gjør det. Blokkerende tilstand kan komme fra tre forskjellige eiere på samme maskin, og hver har sin egen fjerningsvei. Å skylle alt på én gang fjerner objektet du ville bli kvitt, sammen med beskyttelsen du fortsatt trenger, og det ødelegger også beviset for hvilken eier som forårsaket problemet. Fem kontroller, i rekkefølge, hindrer det.

Kontroll 1: hva er fortsatt der, og hva er det for

Se etter de tre artefaktene hver for seg: en virtuell adapter som fortsatt finnes, et brannmurfilter eller en regel som fortsatt blokkerer, og en rute eller policyregel som fortsatt peker på en tunnel som ikke lenger finnes. Tilstedeværelsen deres beviser ingenting i seg selv, fordi en bevisst kill switch ser utenfra lik ut som en forlatt.

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 da tilkoblingen stoppet, og om den vanlige klienten fortsatt kan starte tunnelen sin. Hvis klienten kan gjenopprette tunnelen og trafikken kommer tilbake, gjør blokkeringen jobben sin, og problemet er klientens tilstand, ikke en gjenværende regel.

Kontroll 2: hvilken eier kontrollerer det

Hver artefakt har en eier. Den virtuelle adapteren tilhører VPN-klienten eller driveren dens. Filteret kan tilhøre klienten, plattformens egen brannmur eller et administrert sikkerhetsprodukt. Ruten kan ha blitt installert av klienten ved tilkobling og latt være igjen.

På administrert utstyr, sjekk enhetspolicyen før du rører noe. Et filter som håndheves av policy, blir gjenopprettet ved neste innsjekking, så en lokal fjerning kjøper en time og en samsvarsrapport. Den samtalen hører til administratoren, ikke til brannmurens grensesnitt.

Kontroll 3: fjern det smaleste som forklarer det

Start med leverandørens støttede vei: en reparasjonsinstallasjon eller en ordentlig avinstallering rydder ofte opp i generert tilstand på riktig måte, inkludert filtre som en manuell fjerning ville overse. Les gjenopprettingsinstruksjonene for den installerte versjonen, fordi rekkefølgen betyr noe, og en avinstallering etter en mislykket fjerning oppfører seg annerledes.

Hvis manuell inspeksjon virkelig er nødvendig, noter regelnavnet, grensesnittet og det oppgitte formålet før du endrer noe, og fjern det objektet ved navn. Å fjerne hver nettverksadapter eller skylle hele regelsettet for å treffe én klient er måten en støttesak blir en gjenoppbygging.

Kontroll 4: DNS og ruter overlever adaptere

Oppløsningstilstand kan overleve tunnelen. En resolver som fortsatt peker på en adresse inne i en tunnel som ikke lenger finnes, produserer tidsavbrudd som ser nøyaktig ut som et brannmurfunn, og den vanlige konklusjonen er den feil.

resolvectl status
ip route get 1.1.1.1
nslookup example.com

Hvis adressen løses opp og en rå tilkobling via IP fungerer, er DNS det gjenværende problemet og ikke filtrering. Hvis begge feiler, gå tilbake til kontroll én med ruten og filteret i hånden.

Kontroll 5: test begge veier på nytt og sett diagnostikken tilbake

Bekreft vanlig tilkobling først, deretter hver gjenværende VPN-profil gjennom sine egne kontroller: koble til, bruk den, koble fra, og bekreft at verten er tilbake til vanlig tilkobling. Den rundturen er testen som beviser at den forlatte blokkeringen er borte og ikke bare omgått.

Til slutt, gjenopprett enhver diagnostisk endring du gjorde underveis. En vellykket opprydding fjerner én forlatt avhengighet; den fjerner ikke vertens generelle beskyttelse, og den bør ikke etterlate en permanent svekket brannmur. Noter hvilken eier som holdt blokkeringen, fordi neste avinstallering vil gi de samme tre kandidatene.