Split-Tunnel schließt weiterhin eine App aus, die Sie deinstalliert haben

Die alte App ist weg, und die Split-Tunnel-Liste enthält immer noch einen Eintrag dafür. Nichts bricht sichtbar, und deshalb bleibt er monatelang dort. Dann installiert jemand ein anderes Programm in denselben Ordner, oder ein verwaltetes Profil stellt die Regel bei jeder Wiederverbindung wieder her, und der Verkehr nimmt einen Pfad, den niemand geplant hat. Die Ausnahme hat den Grund überlebt, aus dem sie entstanden ist.

Beim Aufräumen geht es vor allem um Identität: Worauf die Regel jetzt zeigt und wem die Liste gehört.

Das Symptom: eine Ausnahme, die zu nichts passt

Ein veralteter Eintrag ist im normalen Betrieb unsichtbar. Er wird auf drei Arten sichtbar: Eine App, von der Sie erwartet haben, dass sie durch den Tunnel läuft, geht direkt; ein neues Programm erbt eine alte Ausnahme; oder der Client weigert sich, eine Änderung zu speichern, weil das verwaltete Profil sie überschreibt. Alle drei sehen wie getrennte Fehler aus, und alle drei sind dasselbe Buchhaltungsproblem. Jeder ist billig zu prüfen und teuer falsch zu diagnostizieren.

Beginnen Sie damit, die Regel zu lesen, nicht sie zu löschen.

Finden Sie heraus, was die Regel identifiziert

Split-Tunnel-Implementierungen knüpfen Ausnahmen an unterschiedliche Dinge: einen ausführbaren Pfad, einen Paketnamen, eine Bundle-ID oder eine Route. Eine pfadbasierte Regel zeigt auf eine Datei, die möglicherweise nicht mehr existiert oder inzwischen eine andere Datei ist. Eine paketbasierte Regel zeigt auf eine Identität, die eine Neuinstallation wiederverwenden kann. Lesen Sie die Dokumentation des Clients für das Feld, das Sie betrachten, denn dasselbe Textfeld bedeutet bei verschiedenen Produkten Unterschiedliches. Androids VpnService-Anleitung ist die Referenz für den paketbasierten Fall.

Der angezeigte Name ist der unzuverlässigste Teil des Eintrags, und genau ihn lesen die Leute.

Pfadregeln und Paketregeln verhalten sich unterschiedlich

Eine Pfadregel, die eine Deinstallation überlebt, wird normalerweise wirkungslos, und wirkungslos ist das gute Ergebnis. Das schlechte Ergebnis ist ein Pfad, der wiederverwendet wird, weil die neue ausführbare Datei die Ausnahme still erbt. Paketregeln verhalten sich wieder anders: Ein Produkt kann ein nicht verfügbares Paket ignorieren, es ablehnen oder weiterhin nach Namen abgleichen, wenn etwas Neues diesen Namen beansprucht.

Übertragen Sie keine Annahme von einem Client auf einen anderen. Prüfen Sie, was Ihr Client tatsächlich mit einem fehlenden Ziel macht, am besten, indem Sie die Bedingung bewusst auf einem Testrechner herstellen und beobachten, welcher Prozess die Ausnahme erbt.

Entfernen Sie ihn über den Eigentümer

Wenn die Liste aus einem verwalteten Profil stammt, ist eine lokale Bearbeitung eine vorübergehende Änderung, die bei der nächsten Wiederverbindung zurückgesetzt wird. Ändern Sie das Profil oder fragen Sie denjenigen, dem es gehört, und bestätigen Sie, dass die Änderung eine Wiederverbindung übersteht. Wenn die Liste lokal ist, entfernen Sie den Eintrag und prüfen Sie, ob der Client seine Konfiguration neu geschrieben hat, statt die alte im Speicher zu behalten.

Eine leere Liste ist nicht das Ziel. Ziel ist eine Liste, deren Einträge noch echten Anforderungen entsprechen.

Testen Sie danach beide Richtungen

Testen Sie nach dem Aufräumen eine App, die weiterhin ausgeschlossen sein sollte, und eine App, die jetzt durch den Tunnel laufen sollte. Bestätigen Sie das DNS-Verhalten separat, denn die Resolver-Richtlinie ist eine andere Kontrolle als die Ausschlussliste. Verbinden Sie sich dann einmal neu und testen Sie erneut, denn ein wiederhergestelltes Profil ist der häufigste Weg, auf dem ein Aufräumen sich still selbst rückgängig macht.

Halten Sie neben jeder verbleibenden Ausnahme einen einzeiligen Zweck fest. Diese Zeile ist es, die verhindert, dass die Liste ein Museum wird, und sie macht das nächste Aufräumen zu einer Fünf-Minuten-Arbeit.