Split-Tunneling gegen Unternehmensrichtlinie: Welche Regel gewinnt

Eine App in einem Split-Tunnel-Client anzuhaken fühlt sich wie eine lokale Vorliebe an, doch auf einem verwalteten Gerät kommt das einer Richtlinienänderung näher. Die Ausnahme lenkt Verkehr vom genehmigten Pfad weg, der womöglich derselbe ist, über den verwaltetes DNS, Filterung und die Quelladresse laufen, an der ein Dienst das Gerät erkennt. Der Client verhält sich nicht falsch, wenn er Ihre Änderung zurücksetzt; die Bereitstellung tut, was sie soll.

Bevor Sie über das Kontrollkästchen streiten, klären Sie, welche Eigenschaft die Richtlinie schützen soll.

Die Eigenschaft hinter der Regel

Manche Bereitstellungen leiten alles, damit der gesamte Verkehr ein genehmigtes Gateway passiert. Anderen geht es um die Namensauflösung, damit Abfragen beim Unternehmens-Resolver und nicht beim lokalen Netzwerk landen. Wieder andere brauchen eine stabile Quelladresse, damit interne Dienste entscheiden können, ob sie überhaupt antworten.

Eine vierte Gruppe erzwingt den Zustand des Endpunkts: Status der Datenträgerverschlüsselung, Patch-Stand, Zustand des Agenten. Das Aufteilen des Tunnels ändert daran nichts, während eine Umgehung, die den eigenen Verkehr des Agenten meidet, es durchaus kann.

Das sind vier verschiedene Anforderungen, und jede wird von einer anderen Ausnahme verletzt. Lesen Sie die Anforderung, bevor Sie die Änderung vorschlagen, denn wer sie geschrieben hat, kann Ihnen sofort sagen, welche gilt. Eine Änderung, die die falsche erfüllt, bringt nichts.

Zwei Behauptungen sollten Sie früh verwerfen. Vollständiges Tunneling gibt Administratoren nicht jede Klartextseite in die Hand, denn Anwendungsverschlüsselung und Endpoint-Kontrollen bestimmen, was sichtbar ist. Split-Tunneling ist auch nicht grundsätzlich unsicher, weil verwaltetes DNS, App-Richtlinien und Endpoint-Agenten unabhängig von der Route greifen können.

Die Prüfungen in der richtigen Reihenfolge

Die folgende Reihenfolge verkleinert eine Ausnahme auf das kleinste Element, das tatsächlich versagt hat. Hören Sie bei der ersten Prüfung auf, die nicht hält, denn ein späterer Fix kann eine frühere Lücke nicht ausgleichen.

Fragen Sie, welcher Verkehr das genehmigte Gateway jetzt verfehlt, und bestätigen Sie dann, dass die Namensauflösung noch den Unternehmens-Resolver erreicht. Prüfen Sie, ob die betreffende Anwendung einen Kill Switch respektiert oder ob sie den fehlgeschlagenen Versuch auf einer direkten Route verbracht hat. Schauen Sie danach auf gemeinsame Dienste: Ein Dokumentbetrachter oder ein Update-Broker kann die Ausnahme weiter tragen, als das Kontrollkästchen vermuten lässt. Notieren Sie schließlich, ob die Richtlinie bei einer Neuverbindung erneut greift, denn dieses Verhalten entscheidet, ob eine lokale Änderung überhaupt überlebt.

Jede Antwort ist eine Tatsache, und Tatsachen braucht ein Ausnahmeantrag. Ein Argument darüber, ob das VPN nervt, gehört nicht dazu. Schreiben Sie die Antworten auf, bevor das Gespräch beginnt.

Eine enge Ausnahme beantragen

Melden Sie die Anwendung, das Ziel und den Vorgang, der fehlgeschlagen ist, in dieser Reihenfolge. Ein Antrag, einen Updater auf dem direkten Pfad zu halten, ist prüfbar; ein Antrag, den Tunnel für den ganzen Browser zu umgehen, ist es nicht.

Beschreiben Sie, was Sie bereits versucht haben und was die Protokolle zeigten, und richten Sie es an das Team, dem das Profil gehört, statt an die Person am Helpdesk. Auf einem verwalteten Gerät kann der Profilinhaber meist eine unterstützte Ausnahme schaffen, die Updates übersteht, während eine lokale Routenänderung das nicht kann.

Lautet die Antwort nein, behandeln Sie das als Designentscheidung und nicht als Hindernis, das man umgeht. Beim nächsten Review ist der Ort, es erneut aufzugreifen, mit dem dokumentierten fehlgeschlagenen Vorgang und der geschäftlichen Begründung. Daran vorbeizuarbeiten riskiert mehr, als die Ausnahme je wert war.

Die Ausnahme überlebensfähig machen

Bestätigen Sie nach einer genehmigten Änderung die Teile, die vorher funktionierten, nicht nur den Teil, der defekt war. Interne Namen sollten weiterhin über den Unternehmens-Resolver aufgelöst werden, private Ressourcen sollten weiterhin antworten, und die zuvor fehlgeschlagene Aufgabe sollte nun abschließen.

resolvectl query intranet.corp.example
curl -sS -o /dev/null -w '%{http_code}
' https://intranet.corp.example/status

Der erste Befehl beweist, dass der Resolver für ein internes Suffix noch antwortet, und der zweite beweist, dass eine Anfrage den internen Dienst über die aktuelle Route erreicht. Führen Sie sie nach einer Neuverbindung erneut aus, denn eine Richtlinienauslieferung kann still rückgängig machen, was im Test stabil wirkte. Zwei Zeilen Ausgabe, die beim Ticket liegen, schließen den Kreis. Ohne sie ruht die Ausnahme auf jemandes Erinnerung an eine Seite, die einmal geladen wurde.

Halten Sie die Ausnahme, ihren Zweck und die abgedeckten Komponenten am selben Ort wie die Bereitstellungsnotizen fest. Eine undokumentierte Ausnahme wird zum Vorfall des nächsten Quartals, und eine dokumentierte wird zum Beleg dafür, dass das Design eine reale Arbeitslast trägt.