Ingen internet efter afinstallation af VPN? Tjek tre ejere

Klienten er væk, og maskinen kan stadig ikke nå noget, hvilket frister til at jævne firewallen og begynde forfra. Det må du ikke gøre. Blokeringstilstand kan komme fra tre forskellige ejere på samme maskine, og hver har sin egen fjernelsesvej. At skylle alt på én gang fjerner det objekt, du ville af med, sammen med den beskyttelse, du stadig har brug for, og det ødelægger også beviset for, hvilken ejer der forårsagede problemet. Fem kontroller, i rækkefølge, forhindrer det.

Kontrol 1: hvad er der endnu, og hvad tjener det til

Se efter de tre artefakter hver for sig: en virtuel adapter, der stadig findes, et firewall-filter eller en regel, der stadig blokerer, og en rute eller politikregel, der stadig peger på en tunnel, som ikke længere findes. Deres tilstedeværelse beviser intet i sig selv, fordi en bevidst kill switch ser udefra ud som en efterladt.

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 tidspunktet ned, hvor forbindelsen stoppede, og om den normale klient stadig kan starte sin tunnel. Hvis klienten kan gendanne tunnelen, og trafikken vender tilbage, gør blokeringen sit arbejde, og problemet er klientens tilstand, ikke en resterende regel.

Kontrol 2: hvilken ejer styrer det

Hver artefakt har en ejer. Den virtuelle adapter tilhører VPN-klienten eller dens driver. Filteret kan tilhøre klienten, platformens egen firewall eller et administreret sikkerhedsprodukt. Ruten kan være installeret af klienten ved forbindelse og efterladt.

På administreret udstyr skal du tjekke enhedspolitikken, før du rører ved noget. Et filter, der håndhæves af politik, gendannes ved næste check-in, så en lokal fjernelse køber en time og en compliance-rapport. Den samtale hører til administratoren, ikke til firewallens brugergrænseflade.

Kontrol 3: fjern det snævreste, der forklarer det

Start med leverandørens understøttede vej: en reparationsinstallation eller en ordentlig afinstallation rydder ofte op i genereret tilstand korrekt, herunder filtre, som en manuel fjernelse ville overse. Læs gendannelsesinstruktionerne for den installerede version, fordi rækkefølgen er vigtig, og en afinstallation efter en mislykket fjernelse opfører sig anderledes.

Hvis manuel inspektion virkelig er nødvendig, skal du notere reglens navn, grænsefladen og det angivne formål, før du ændrer noget, og fjerne det objekt ved navn. At fjerne hver netværksadapter eller skylle hele regelsættet for at ramme én klient er måden, hvorpå en supportsag bliver en genopbygning.

Kontrol 4: DNS og ruter overlever adaptere

Opløsningstilstand kan overleve tunnelen. En resolver, der stadig peger på en adresse inde i en tunnel, som ikke længere findes, giver timeouts, der ser præcis ud som et firewall-drop, og den sædvanlige konklusion er den forkerte.

resolvectl status
ip route get 1.1.1.1
nslookup example.com

Hvis adressen opløses, og en rå forbindelse via IP virker, er DNS det resterende problem og ikke filtrering. Hvis begge fejler, gå tilbage til kontrol et med ruten og filteret i hånden.

Kontrol 5: test begge veje igen, og sæt diagnostikken tilbage

Bekræft først almindelig forbindelse, derefter hver resterende VPN-profil gennem dens egne kontroller: opret forbindelse, brug den, afbryd, og bekræft, at værten er tilbage på almindelig forbindelse. Den rundtur er testen, der beviser, at den efterladte blokering er væk og ikke blot omgået.

Til sidst skal du gendanne enhver diagnostisk ændring, du har foretaget undervejs. En vellykket oprydning fjerner én efterladt afhængighed; den fjerner ikke værtens generelle beskyttelse, og den bør ikke efterlade en permanent lempet firewall. Noter, hvilken ejer der holdt blokeringen, fordi den næste afinstallation vil give de samme tre kandidater.