Internet funktioniert nur mit eingeschalteter VPN-App? Prüfen Sie vier Ebenen

Sie testen eine Woche lang einen kostenlosen VPN-Client oder eine Browsererweiterung, schalten sie aus, und das Internet steht. Das WLAN-Symbol zeigt weiterhin eine Verbindung, andere Geräte am selben Router funktionieren, und das Einzige, was das Surfen zurückbringt, ist die App wieder einzuschalten oder sie zu deinstallieren. Dieses Muster ist keine Verschlüsselung, die eine Abhängigkeit erzeugt. Es ist Konfiguration, die die App irgendwo geschrieben hat, wo der Tunnel nicht der Eigentümer ist.

Der Client ändert Einstellungen, die dem Tunnel nicht gehören

Ein Datenschutz-Client unter Windows oder macOS berührt meist drei Stellen gleichzeitig. Er setzt den HTTP-Systemproxy, also dasselbe Feld, das Internet Options anzeigt. Er installiert einen virtuellen Adapter, oft einen TAP-Treiber, um Pakete abzufangen. Und er schreibt die Resolver-Liste neu, während beim Trennen nur der Tunnel verschwindet.

Eine Browsererweiterung ist eine engere Sache. Sie ändert normalerweise ihr eigenes Profil oder den Proxy, dem ein einzelner Browser folgt. Deshalb kann ein Browser ausfallen, während Kommandozeilenwerkzeuge weiterlaufen, oder umgekehrt: Die Erweiterung hatte nie die Befugnis, die anderen Ebenen zu berühren. Welche Ebene sie bearbeitet hat, entscheidet, welche Werkzeuge brechen.

So oder so wurde die veraltete Entscheidung von Software getroffen, die keinen Grund hatte, sie rückgängig zu machen. Der Tunnel war der sichtbare Teil, und er war auch der einzige Teil mit einem sauberen Abschaltpfad. Alles andere ist eine Einstellung in einem Speicher, der den Prozess überlebt, also ist das Entfernen der App der eine Schritt, der alle drei auf einmal zurückdreht. Diese Speicher zu lesen, bevor man irgendetwas neu installiert, macht aus dem Symptom eine Diagnose.

Drei Überbleibsel, drei verschiedene Fehler

Das erste Überbleibsel ist ein Proxy, der ins Nichts zeigt: das LAN-Proxy-Kästchen noch angehakt, oder eine Konfigurationsskript-URL auf einen localhost-Port gerichtet, an dem kein Prozess mehr lauscht. Der Browser schickt jede Anfrage an diesen toten Port und hängt, bis das Zeitlimit wie ein totes Netz aussieht. Das zweite ist ein Adapter, der noch eine Standardroute besitzt, weil ein TAP-Windows-Gerät oder ein Routing-Treiber eines Herstellers nach der Deinstallation eine echte Schnittstelle bleibt. Er behält die Route, die er bekommen hat, und der Verkehr verschwindet in einem Tunnel, der nicht da ist. Keines der beiden Überbleibsel meldet sich; beide sehen genau wie ein Ausfall aus.

Das dritte ist DNS, und es scheitert früher als die anderen zwei. Enthält die Resolver-Liste nur Server, die durch den Tunnel erreichbar sind, läuft jede Auflösung ab, bevor eine einzige Seite angefragt wird, also meldet der Browser eine unerreichbare Seite statt eines toten Proxys. Welches Sie auch haben, keines ist ein Ausfall im Netzwerksinn. Jedes ist ein Überbleibsel, das niemand widerrufen hat, und jedes wird an einer anderen Stelle repariert.

Arbeiten Sie die vier Ebenen ab

Beginnen Sie am nächsten zur Anwendung und arbeiten Sie sich nach unten, weil die Ebenen genau in dieser Reihenfolge der Sichtbarkeit scheitern. Ändern Sie eine Ebene pro Test und testen Sie nach jeder. Alles auf einmal zurückzusetzen stellt das Surfen meist wieder her und lässt Sie nicht sagen, welches Überbleibsel es verursacht hat, sodass die nächste Installation dasselbe Rätsel neu erzeugt. Die Reihenfolge ist Proxy, Adapter, Routen, Resolver.

Unter Windows ist jede Prüfung ein einzelner Befehl, der zum Betriebssystem gehört, es muss also nichts installiert werden. Führen Sie sie der Reihe nach aus und halten Sie die Ausgabe zusammen, weil die vier Antworten nur nebeneinander Sinn ergeben. Sie melden den Proxy, die Adapter, die IPv4-Routen und die Resolver-Liste, in dieser Reihenfolge:

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

Linux und macOS brauchen eigene Befehle, und sie sind nicht austauschbar. Unter Linux kommen die Routen aus ip route und der Resolver aus resolvectl status, wo systemd-resolved ihn besitzt, mit Rückfall auf cat /etc/resolv.conf. Unter macOS kommen die Routen aus netstat -rn, die Resolver aus scutil --dns und der Systemproxy aus scutil --proxy. Ein macOS-Leser, der ip route ausführt, bekommt command not found, und /etc/resolv.conf ist dort ein generierter Stub und nicht die maßgebliche Konfiguration. Prüfen Sie die Plattform, bevor Sie die Ebene prüfen, sonst wird der erste Befehl zum Befund.

Stellen Sie für jede Ebene eine Frage: Zeigt dieser Wert noch auf etwas, das existiert, während die App geschlossen ist? Ein Proxy an einem toten Port, ein Adapter ohne Tunnel, eine Standardroute über eine ausgefallene Schnittstelle und ein Resolver im Tunnel antworten alle mit nein. Ein einziges Nein genügt, um das Symptom zu erklären, deshalb zählt eine Änderung pro Test.

Ein Proxy ist kein Tunnel

Ein Proxy nimmt eine Anfrage an, holt sie anderswo und gibt die Antwort zurück, das heißt, er kennt das Ziel und sieht alles, was die Seite nicht selbst verschlüsselt hat. Er trägt keine anderen Protokolle. Er schützt den Pfad nicht, außer das Ziel verwendet bereits TLS. Und er kann von dem geändert werden, was ihn installiert hat, ohne Ihr Zutun.

Diese Unterscheidung ändert die Frage, die sich zu stellen lohnt. Wenn ein Proxy zurückbleibt, finden Sie heraus, welches Programm Ihren Browser noch lenkt, statt ob der Tunnel steht. Der Tunnel kann völlig gesund und für den Fehler völlig unerheblich sein.

Wenn Sie wissen wollen, was so ein Client tatsächlich getan hat, beobachten Sie ihn, statt sein Dashboard zu lesen. Process Monitor zeichnet auf, welche Registrierungsschlüssel und Dateien er berührt, während eine Paketaufzeichnung zeigt, wohin sein Verkehr ging. Beides sind gewöhnliche Werkzeuge, und beide beantworten die Überbleibsel-Frage besser als jede Statusleuchte. Keines von beiden verlangt, dass die App noch läuft.

Entfernen Sie die Komponente, nicht die Beweise

Die dauerhafte Lösung ist, das zu entfernen, was die Einstellung geschrieben hat. Deinstallieren Sie die App, löschen Sie den virtuellen Adapter, den sie hinzugefügt hat, räumen Sie Proxy und Resolver-Liste auf, starten Sie neu und testen Sie, während die App noch deinstalliert ist. Wenn das Surfen dann funktioniert, haben Sie die Ursache gefunden und keine Notlösung. Notieren Sie, welche Ebene veraltet war, denn derselbe Hersteller macht gern denselben Fehler zweimal.

Kommt das Symptom nach der Installation des nächsten Clients zurück, gehen Sie die vier Ebenen erneut durch, bevor Sie entscheiden, dass der Dienst etwas kaputt gemacht hat. Die Beweise sind meist noch da, an einem der vier Orte. Eine zweite App erzeugt keine fünfte Ebene; sie bearbeitet eine der vier.

Eine Neuinstallation setzt den Proxy zurück, aber keinen veralteten Adapter, und sie kann zwei Resolver in der Liste lassen. Diese Asymmetrie ist der Grund, warum Deinstallieren-dann-Testen einen Alles-zurücksetzen-Knopf schlägt. Sie gibt Ihnen auch eine Ausgangsbasis für den Vergleich, wenn die Verbindung das nächste Mal abbricht.