Prüfen, ob ein Split-Tunnel funktioniert: ein IP-Ergebnis ist kein Test

Eine einzelne Browserseite, die eine IP-Adresse anzeigt, beweist fast nichts über einen Split-Tunnel. Eine sichtbare Adresse kann aus dem falschen Grund die richtige sein, und ein ausgeschlossener Fluss wird von ihr nie erfasst. Schreiben Sie das erwartete Ergebnis vor dem Test auf: welche Anwendung oder welches Ziel den Tunnel nutzen soll, welche direkt bleiben soll und was stoppen muss, wenn der Tunnel ausfällt. Ohne diesen Plan sieht jede plausible Zahl wie ein Erfolg aus.

Der Mythos: eine Adressabfrage beweist Abdeckung

Die IP-Prüfung beantwortet eine Frage: was die Außenwelt zu einem Zeitpunkt von einer Anwendung sieht. Sie sagt nichts über ein internes Präfix, ein zweites Browserprofil oder einen Namen, der privat aufgelöst werden soll. Sie sagt auch nichts über den Ausfall, und das ist die Hälfte eines Split-Tunnel-Designs, die im Produktivbetrieb bricht.

Eine Adressseite kann auch die Route, den Resolver oder die Ausfallrichtlinie nicht zeigen. Behandeln Sie sie als eine Beobachtung, nicht als ein Urteil.

Einen eingeschlossenen und einen ausgeschlossenen Fluss prüfen

Senden Sie eine harmlose Anfrage aus der Anwendung, die eingeschlossen sein soll, oder an das Präfix, das Sie durch den Tunnel leiten erwarten, und protokollieren Sie Quelle, Ziel, Adressfamilie und beobachteten Pfad. Tun Sie dasselbe für einen Fluss, der direkt bleiben soll. Die ausgeschlossene Seite ist die, die man überspringt, und sie ist der einzige Beleg dafür, dass die Teilung absichtlich und nicht zufällig ist. Ein Hilfsprozess kann eine eigene Richtlinienidentität tragen, also testen Sie in dem Prozess, der den Socket besitzt.

flow: Firefox to intranet.example:443, IPv4, source 10.8.0.6, tunneled
flow: Firefox to 1.1.1.1, IPv4, source 192.0.2.20, direct

Deshalb kann ein Test in der falschen Anwendung das Gegenteil dessen zeigen, was das Design beabsichtigt. Schreiben Sie die vier Felder für beide Seiten auf, bevor Sie eine Schlussfolgerung ziehen.

DNS und den Ausfallfall ergänzen

Fragen Sie den Systemresolver und den Resolver ab, den die App nutzt, und vergleichen Sie diese Antworten dann mit der Ausgangsadresse, die die Website meldet. Die beiden Ebenen können sich absichtlich widersprechen, und eine einzelne Browserabfrage prüft die Richtlinie des Betriebssystems nicht. Eine Shell macht den Vergleich wiederholbar: Brechen Sie den Tunnel absichtlich, stellen Sie dann eine Anfrage, die der Browser nicht zwischengespeichert hat; eine aus dem Cache gelieferte Seite sagt nichts darüber aus, in welche Richtung der Rückfall ging. Halten Sie fest, was tatsächlich geschah, statt was das Design vorhersagte.

curl -s https://ifconfig.me
nslookup intranet.example

Ein Split-Tunnel, der geschlossen ausfällt, und einer, der offen ausfällt, sehen identisch aus, bis Sie den Tunnel absichtlich brechen. Halten Sie fest, welches Verhalten Sie beobachtet haben, nicht welches Sie erwartet haben.

Nach der Zustandsänderung wiederholen

Wiederholen Sie dieselben Beobachtungen nach einer Wiederverbindung, einem Netzwerkwechsel und einem relevanten Anwendungsupdate. Eine gespeicherte Ausnahme kann weiter auf einen Pfad oder eine Anwendungsidentität zeigen, die es nicht mehr gibt, und das Design passt stillschweigend nicht mehr zu seiner Dokumentation. Diese drei Ereignisse sind die Stellen, an denen Split-Tunnel abdriften, und jedes davon ist billig erneut zu testen. Ein Test, der nur einmal beim Rollout läuft, beschreibt eine Konfiguration, die es nicht mehr gibt.

Wenn ein Ergebnis abweicht, finden Sie den Eigentümer der Regel und die Verarbeitungsstufe, bevor Sie mehrere Einstellungen auf einmal ändern. Fünf Dinge zu ändern und ein Ergebnis zu beobachten ist keine Diagnose, sondern eine neue Konfiguration.

Was das Ergebnis belegen soll

Binden Sie die Beobachtungen an die Richtlinie und Client-Version, die Sie tatsächlich getestet haben. Das Ziel ist zu zeigen, dass diese Bereitstellung der Abdeckung entspricht, die sie beansprucht, nicht dass jede künftige Anwendung privat sein wird. Das ist eine engere Behauptung, und sie ist die, die Sie tatsächlich mit Belegen stützen können. Schreiben Sie die Behauptung, die Version und die Vier-Feld-Ergebnisse in den Änderungsdatensatz.

Dann kann der nächste Prüfer erkennen, ob sich das Design geändert hat oder der Test. Ein Split-Tunnel ist verifiziert, wenn beide Seiten, die Resolver-Teilung und das Ausfallverhalten dem entsprechen, was Sie zu Beginn aufgeschrieben haben. Ein IP-Ergebnis verifiziert nichts davon.