Inget internet efter avinstallation av VPN? Kontrollera tre ägare

Klienten är borta och maskinen når fortfarande ingenting, vilket frestar till att jämna ut brandväggen och börja om. Gör inte det. Blockerande tillstånd kan komma från tre olika ägare på samma maskin, och var och en har sin egen borttagningsväg. Att spola allt på en gång tar bort objektet du ville bli av med tillsammans med skyddet du fortfarande behöver, och det förstör också beviset för vilken ägare som orsakade problemet. Fem kontroller, i ordning, förhindrar det.

Kontroll 1: vad finns kvar, och vad är det till för

Leta efter de tre artefakterna var för sig: en virtuell adapter som fortfarande finns, ett brandväggsfilter eller en regel som fortfarande blockerar, och en rutt eller policyregel som fortfarande pekar på en tunnel som inte längre finns. Deras närvaro bevisar ingenting i sig, eftersom en avsiktlig nödstopp ser utifrån ut precis som en övergiven.

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 ner tiden då anslutningen slutade och om den vanliga klienten fortfarande kan starta sin tunnel. Om klienten kan återställa tunneln och trafiken kommer tillbaka gör blockeringen sitt jobb, och problemet är klientens tillstånd, inte en kvarvarande regel.

Kontroll 2: vilken ägare som styr det

Varje artefakt har en ägare. Den virtuella adaptern tillhör VPN-klienten eller dess drivrutin. Filtret kan tillhöra klienten, plattformens egen brandvägg eller en hanterad säkerhetsprodukt. Rutten kan ha installerats av klienten vid anslutning och lämnats kvar.

På hanterad utrustning, kontrollera enhetspolicyn innan du rör något. Ett filter som upprätthålls av policy återställs vid nästa incheckning, så en lokal borttagning köper en timme och en efterlevnadsrapport. Det samtalet hör till administratören, inte till brandväggens gränssnitt.

Kontroll 3: ta bort det smalaste som förklarar det

Börja med leverantörens stödda väg: en reparationsinstallation eller en korrekt avinstallation städar ofta upp genererat tillstånd på rätt sätt, inklusive filter som en manuell borttagning skulle missa. Läs återställningsinstruktionerna för den installerade versionen, eftersom ordningen spelar roll och en avinstallation efter en misslyckad borttagning beter sig annorlunda.

Om manuell inspektion verkligen behövs, notera regelns namn, gränssnittet och det angivna syftet innan du ändrar något, och ta bort objektet vid namn. Att ta bort varje nätverksadapter eller spola hela regeluppsättningen för att träffa en enda klient är sättet en supportärende blir en återuppbyggnad.

Kontroll 4: DNS och rutter överlever adaptrar

Upplösningstillstånd kan överleva tunneln. En resolver som fortfarande pekar på en adress inne i en tunnel som inte längre finns producerar tidsgränser som ser exakt ut som ett brandväggsfall, och den vanliga slutsatsen är den felaktiga.

resolvectl status
ip route get 1.1.1.1
nslookup example.com

Om adressen löses upp och en rå anslutning via IP fungerar är DNS det kvarvarande problemet och inte filtrering. Om båda misslyckas, gå tillbaka till kontroll ett med rutten och filtret i handen.

Kontroll 5: testa båda vägarna igen och sätt tillbaka diagnostiken

Verifiera vanlig anslutning först, sedan varje kvarvarande VPN-profil via sina egna kontroller: anslut, använd, koppla från och bekräfta att värden är tillbaka på vanlig anslutning. Den rundturen är testet som bevisar att den övergivna blockeringen är borta och inte bara kringgås.

Återställ slutligen alla diagnostiska ändringar du gjorde längs vägen. En lyckad städning tar bort ett övergivet beroende; den tar inte bort värdens allmänna skydd, och den bör inte lämna en permanent uppmjukad brandvägg efter sig. Notera vilken ägare som höll blockeringen, eftersom nästa avinstallation ger samma tre kandidater.