Internet werkt alleen met de VPN-app aan? Controleer vier lagen

Je probeert een week lang een gratis VPN-client of een browserextensie, zet hem uit en het internet stopt. Het wifi-pictogram toont nog steeds een verbinding, andere apparaten op dezelfde router werken prima, en het enige dat browsen terugbrengt is de app weer aanzetten of hem verwijderen. Dat patroon is geen versleuteling die een afhankelijkheid creëert. Het is configuratie die de app ergens heeft geschreven waar de tunnel geen eigenaar van is.

De client wijzigt instellingen die de tunnel niet bezit

Een privacy-client op Windows of macOS raakt meestal drie plekken tegelijk aan. Hij stelt de systeem-HTTP-proxy in, hetzelfde veld dat Internetopties toont. Hij installeert een virtuele adapter, vaak een TAP-stuurprogramma, zodat hij pakketten kan onderscheppen. En hij herschrijft de resolverlijst, terwijl alleen de tunnel verdwijnt wanneer je op verbreken drukt.

Een browserextensie is iets beperkters. Meestal wijzigt hij zijn eigen profiel of de proxy die één browser volgt. Daarom kan één browser falen terwijl opdrachtregelprogramma's blijven werken, of omgekeerd: de extensie had nooit de bevoegdheid om de andere lagen aan te raken. Welke laag hij heeft bewerkt, bepaalt welke programma's stukgaan.

Hoe dan ook, de verouderde beslissing is genomen door software die geen reden had om hem terug te draaien. De tunnel was het zichtbare deel, en hij was ook het enige deel met een nette afsluitroute. Al het andere is een instelling in een opslag die het proces overleeft, dus de app verwijderen is de enige stap die alle drie tegelijk terugdraait. Die opslagen lezen voordat je iets opnieuw installeert, is wat het symptoom in een diagnose verandert.

Drie restanten, drie verschillende storingen

Het eerste restant is een proxy die nergens naar wijst: het LAN-proxyvakje staat nog aangevinkt, of een configuratiescript-URL wijst naar een localhost-poort waar geen proces meer luistert. De browser stuurt elk verzoek naar die dode poort en blijft hangen tot de time-out op een dood netwerk lijkt. Het tweede is een adapter die nog steeds een standaardroute bezit, omdat een TAP-Windows-apparaat of een leveranciersstuurprogramma voor routering een echte interface blijft na een verwijdering. Hij houdt de route die hem is gegeven, en verkeer verdwijnt in een tunnel die er niet is. Geen van beide restanten kondigt zichzelf aan; beide zien er precies uit als een storing.

Het derde is DNS, en dat faalt eerder dan de andere twee. Als de resolverlijst alleen servers bevat die via de tunnel bereikbaar zijn, loopt elke opzoeking af voordat er één pagina wordt opgevraagd, dus meldt de browser een onbereikbare site in plaats van een dode proxy. Welk van de drie je ook hebt, geen ervan is een storing in de netwerkzin. Elk is een restant dat niemand heeft ingetrokken, en elk wordt op een andere plek hersteld.

Werk de vier lagen af

Begin het dichtst bij de toepassing en werk naar beneden, want de lagen falen in die volgorde van zichtbaarheid. Wijzig één laag per test, en test opnieuw na elke wijziging. Alles tegelijk resetten herstelt meestal het browsen, en het laat je niet kunnen zeggen welk restant de oorzaak was, dus de volgende installatie maakt dezelfde puzzel opnieuw. De volgorde is proxy, adapters, routes, resolvers.

Op Windows is elke controle één opdracht die met het besturingssysteem meekomt, dus er hoeft niets te worden geïnstalleerd. Voer ze in volgorde uit en houd de uitvoer bij elkaar, want de vier antwoorden zijn alleen naast elkaar zinvol. Ze melden de proxy, de adapters, de IPv4-routes en de resolverlijst, in die volgorde:

netsh winhttp show proxy
Get-NetAdapter
route print -4
Get-DnsClientServerAddress

Linux en macOS hebben hun eigen opdrachten nodig, en die zijn niet uitwisselbaar. Op Linux komen de routes van ip route en de resolver van resolvectl status waar systemd-resolved eigenaar is, met terugval op cat /etc/resolv.conf. Op macOS komen de routes van netstat -rn, de resolvers van scutil --dns en de systeemproxy van scutil --proxy. Een macOS-lezer die ip route uitvoert krijgt command not found, en /etc/resolv.conf is daar een gegenereerde stub in plaats van de gezaghebbende configuratie. Controleer het platform voordat je de laag controleert, anders wordt de eerste opdracht zelf de bevinding.

Stel voor elke laag één vraag: wijst deze waarde nog naar iets dat bestaat terwijl de app gesloten is? Een proxy op een dode poort, een adapter zonder tunnel, een standaardroute via een interface die uit staat en een resolver binnen de tunnel antwoorden allemaal nee. Elke enkele nee is genoeg om het symptoom te verklaren, en daarom is één wijziging per test belangrijk.

Een proxy is geen tunnel

Een proxy neemt een verzoek aan, haalt het elders op en geeft het antwoord terug, wat betekent dat hij de bestemming kent en alles ziet wat de site zelf niet heeft versleuteld. Hij draagt geen andere protocollen. Hij beschermt het pad niet, tenzij de bestemming al TLS gebruikt. En hij kan worden gewijzigd door wat hem ook maar heeft geïnstalleerd, zonder dat jij erbij betrokken bent.

Dat onderscheid verandert de vraag die de moeite waard is. Wanneer er een proxy achterblijft, zoek dan uit welk programma je browser nog stuurt in plaats van of de tunnel actief is. De tunnel kan volledig gezond en volstrekt irrelevant voor de storing zijn.

Als je wilt weten wat zo'n client werkelijk heeft gedaan, kijk dan mee in plaats van zijn dashboard te lezen. Process Monitor legt vast welke registersleutels en bestanden hij aanraakt, terwijl een pakketopname laat zien waar zijn verkeer heen ging. Beide zijn gewone hulpmiddelen, en beide beantwoorden de restantvraag beter dan welk statuslampje ook. Geen van beide vereist dat de app nog draait.

Verwijder het onderdeel, niet het bewijs

De duurzame oplossing is het verwijderen van wat de instelling heeft geschreven. Verwijder de app, verwijder de virtuele adapter die hij toevoegde, wis de proxy en de resolverlijst, herstart en test terwijl de app nog steeds verwijderd is. Als browsen dan werkt, heb je de oorzaak gevonden in plaats van een omweg. Noteer welke laag verouderd was, want dezelfde leverancier levert dezelfde fout vaak twee keer.

Als het symptoom terugkomt nadat je de volgende client hebt geïnstalleerd, loop de vier lagen dan opnieuw af voordat je besluit dat de dienst iets heeft stukgemaakt. Het bewijs staat meestal nog in een van de vier plekken. Een tweede app maakt geen vijfde laag; hij bewerkt een van de vier.

Opnieuw installeren reset de proxy maar niet een verouderde adapter, en het kan twee resolvers in de lijst achterlaten. Die asymmetrie is waarom verwijderen-dan-testen het wint van een alles-resetten-knop. Het geeft je ook een basislijn om mee te vergelijken de volgende keer dat de verbinding wegvalt.