Geen internet na het verwijderen van de VPN? Controleer drie eigenaren

De client is weg en de machine bereikt nog steeds niets, wat verleidt tot het platgooien van de firewall en opnieuw beginnen. Doe dat niet. Blokkerende toestand kan van drie verschillende eigenaren op dezelfde machine komen, en elk heeft zijn eigen verwijderingspad. Alles in één keer wegspoelen verwijdert het object dat u kwijt wilde samen met bescherming die u nog nodig hebt, en het vernietigt ook het bewijs van welke eigenaar het probleem veroorzaakte. Vijf controles, in volgorde, voorkomen dat.

Controle 1: wat is er nog, en waarvoor dient het

Zoek de drie artefacten afzonderlijk: een virtuele adapter die nog bestaat, een firewallfilter of -regel die nog blokkeert, en een route of beleidsregel die nog naar een tunnel wijst die niet meer bestaat. Hun aanwezigheid bewijst op zichzelf niets, want een opzettelijke kill switch ziet er van buiten hetzelfde uit als een verlaten exemplaar.

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

Noteer het tijdstip waarop de connectiviteit stopte en of de normale client zijn tunnel nog kan starten. Als de client de tunnel kan herstellen en het verkeer terugkomt, doet de blokkering zijn werk en zit het probleem in de staat van de client, niet in een achtergebleven regel.

Controle 2: welke eigenaar beheert het

Elk artefact heeft een eigenaar. De virtuele adapter is van de VPN-client of zijn stuurprogramma. Het filter kan van de client, van de firewall van het platform zelf of van een beheerd beveiligingsproduct zijn. De route is mogelijk door de client bij het verbinden geïnstalleerd en achtergelaten.

Op beheerde apparatuur, controleer het apparaatbeleid voordat u iets aanraakt. Een filter dat door beleid wordt afgedwongen, wordt bij de volgende check-in hersteld, dus een lokale verwijdering koopt een uur en een nalevingsrapport. Dat gesprek hoort bij de beheerder, niet bij de firewall-interface.

Controle 3: verwijder het smalste dat het verklaart

Begin met het door de leverancier ondersteunde pad: een reparatie-installatie of een correcte verwijdering ruimt gegenereerde toestand vaak goed op, inclusief filters die een handmatige verwijdering zou missen. Lees de herstelinstructies voor de geïnstalleerde versie, want de volgorde is belangrijk en een verwijdering na een mislukte verwijdering gedraagt zich anders.

Als handmatige inspectie echt nodig is, noteer dan de regelnaam, de interface en het opgegeven doel voordat u iets wijzigt, en verwijder dat object op naam. Elke netwerkadapter verwijderen of de hele regelset wegspoelen om één client te targeten is de manier waarop een supportcase een herbouw wordt.

Controle 4: DNS en routes overleven adapters

Resolutietoestand kan de tunnel overleven. Een resolver die nog naar een adres binnen een tunnel wijst die niet meer bestaat, produceert time-outs die er precies als een firewall-drop uitzien, en de gebruikelijke conclusie is de verkeerde.

resolvectl status
ip route get 1.1.1.1
nslookup example.com

Als het adres wordt opgelost en een ruwe verbinding via IP werkt, is DNS het resterende probleem en niet filtering. Als beide mislukken, ga terug naar controle één met de route en het filter in de hand.

Controle 5: test beide paden opnieuw en zet de diagnostiek terug

Controleer eerst gewone connectiviteit en daarna elk resterend VPN-profiel via zijn eigen bediening: verbind, gebruik, verbreek, en bevestig dat de host terug is bij gewone connectiviteit. Die rondreis is de test die bewijst dat de achtergelaten blokkering weg is en niet slechts omzeild.

Herstel ten slotte elke diagnostische wijziging die u onderweg hebt gemaakt. Een geslaagde opruiming verwijdert één achtergebleven afhankelijkheid; het verwijdert niet de algemene bescherming van de host, en het zou geen permanent versoepelde firewall achter moeten laten. Noteer welke eigenaar de blokkering vasthield, want de volgende verwijdering levert dezelfde drie kandidaten op.