VPN-Ausnahmen pro App scheitern, wenn ein gemeinsamer Dienst Daten abruft

Sie schließen eine Anwendung vom VPN aus, und der benötigte Download schlägt weiterhin fehl, oder schlimmer, er funktioniert plötzlich, und etwas Unbeteiligtes hört auf zu funktionieren. Das sichtbare Fenster ist nicht zwangsläufig der Prozess, der jede Verbindung öffnet: Eine Anwendung kann Arbeit an einen Helfer, einen Hintergrund-Übertragungsdienst oder ein ganz anderes Paket übergeben. Eine Regel pro App braucht daher das echte Identitätsmodell der Plattform statt eines vertrauten Launcher-Dateinamens. Die folgenden Prüfungen beginnen bei der Beobachtung und arbeiten sich zu dem zurück, der die Anfrage tatsächlich gestellt hat.

In diesen Tickets gehen meist zwei Dinge gleichzeitig schief: Die falsche Komponente wird ausgeschlossen, und die Ausnahme wird danach nie eingegrenzt.

Finden Sie den Prozess, nicht das Fenster

Reproduzieren Sie den fehlgeschlagenen Vorgang und identifizieren Sie den Prozess oder das Paket, dem die Verbindung gehört, während sie stattfindet. Unter Windows ist das eine andere Frage als die, welches Fenster den Fokus hat, denn eine Hintergrundübertragung kann von einem Dienst vermittelt werden, der unter seiner eigenen Identität läuft. Unter Linux und macOS erscheint dieselbe Trennung als Hilfsprozesse und Systemdienste.

Notieren Sie drei Details: die Identität der ausführbaren Datei oder des Pakets, das Ziel, das kontaktiert wurde, und den Moment im Ablauf, in dem es geschah. Ein Download, der am Anfang scheitert, ist oft ein Metadatenabruf einer anderen Komponente als ein Download, der auf halbem Weg scheitert. Diese Unterscheidung allein reicht meist, um die richtige Identität zu wählen, bevor Sie die Regel anfassen. Stellt sich die Identität als Dienst statt als App heraus, ändert diese eine Tatsache die ganze Regel, also stellen Sie sie zuerst fest.

Können Sie den Prozess nicht beobachten, weil der Vorgang zu kurz ist, wiederholen Sie ihn mit einer größeren Nutzlast oder einem langsameren Ziel. Das Ziel ist eine reproduzierbare Beobachtung, keine Theorie darüber, welcher Helfer beteiligt ist.

Behandeln Sie DNS als eigenen Pfad

Die Systemnamensauflösung folgt der ausgeschlossenen Anwendung möglicherweise überhaupt nicht, weshalb ein ausgeschlossener Browser an einem privaten Hostnamen weiterhin scheitern kann, obwohl sein Verkehr korrekt außerhalb des Tunnels liegt. Der Browser war ausgeschlossen, der Resolver nicht.

Prüfen Sie, was die Plattform mit DNS macht, wenn eine Regel pro App gilt, und prüfen Sie das getrennt von der HTTP-Anfrage. Ist der Resolver ein gemeinsamer Dienst, bedient er jede Anwendung auf dem Gerät, sodass die Ausnahme, die Sie erwägen, ein viel größeres Publikum hat als die getestete.

Halten Sie fest, welcher Resolver geantwortet hat und über welche Schnittstelle. Diese eine Beobachtung löst einen großen Teil der Meldungen „die App ist ausgenommen, aber der Name wird nicht aufgelöst“, also bewahren Sie sie beim Ticket auf.

Erweitern Sie keinen gemeinsamen Helfer

Ein gemeinsamer Dienst erledigt Arbeit für mehrere Anwendungen, daher verändert sein Ausschluss zur Reparatur eines Ablaufs auch unbeteiligten Verkehr. Der Background Intelligent Transfer Service unter Windows ist ein gutes Beispiel für diese Form: Er ist Infrastruktur, die viele Anwendungen nutzen können, und seine Identität ist nicht die Identität der App, die die Übertragung angefordert hat.

Prüfen Sie das unterstützte Regelmodell des Clients und die Anforderungen der Organisation, bevor Sie diese Ausnahme hinzufügen. Fragen Sie, was sonst die Komponente nutzt, und ob sich die Regel, die Sie schreiben wollen, gegen Ziele statt gegen einen gemeinsamen Prozess ausdrücken lässt.

Lässt sich die Anforderung überhaupt nicht als Anwendungsgrenze ausdrücken, kann eine zielbasierte Richtlinie oder ein anderes genehmigtes Design verständlicher und sicherer sein als eine wachsende Liste von Helfer-Ausnahmen.

Testen Sie den ganzen Ablauf, nicht den fehlgeschlagenen Schritt

Führen Sie nach einer unterstützten Änderung die beabsichtigte Aufgabe mit einer frischen Anfrage von Anfang bis Ende aus. Führen Sie dann einen anderen Ablauf aus, der die gemeinsame Komponente nutzt, denn dort meldet sich eine breite Umgehung. Eine Korrektur, die den ersten repariert und den zweiten still bricht, ist keine Korrektur. Halten Sie beide Ergebnisse im Ticket fest und benennen Sie den zweiten Ablauf ausdrücklich, damit ein Prüfer ihn wiederholen kann.

Halten Sie den Test klein und wiederholbar: dasselbe Ziel, dasselbe Konto, dieselben Bedingungen. Ist der zweite Ablauf nicht dokumentiert, fragen Sie seinen Eigentümer, wovon er abhängt, bevor Sie entscheiden, dass die Änderung sicher ist.

Hinterlassen Sie einen Grund, keine Namensliste

Dokumentieren Sie die Komponente, den Ablauf, dem sie dient, und den Grund für ihren Ausschluss. Eine Liste von Helfernamen ohne zugehörigen Zweck wird innerhalb von zwei Release-Zyklen unwartbar, und der nächste Ingenieur entfernt beim Aufräumen den falschen Eintrag.

Eine Zeile pro Ausnahme genügt: was ohne sie bricht, wer diesen Ablauf besitzt und wann er zuletzt überprüft wurde. Diese drei Felder machen aus einer Rätselliste eine Richtlinie, die jemand verteidigen kann.