Wo eine Android-Firewall-Regel leben muss, wenn ein VPN aktiv ist

Sie haben einen Satz Richtlinie: Diese App darf den Arbeitsdienst erreichen und sonst nichts. Die nächste Frage sieht nach einer Produktentscheidung aus, ist aber eine Ortsfrage, denn jede mögliche Durchsetzungsstelle sieht einen anderen Teil des Datenverkehrs des Telefons. Das Gateway sieht nur, was in den Tunnel eintritt. Der Filter auf der Telefonseite sieht nur, was er beobachten darf. Eine einzige Anfrage durch beide zu führen, macht die Antwort offensichtlich.

Mit dem Satz beginnen, nicht mit dem Produkt

Erweitern Sie die Anforderung, bevor Sie etwas auswählen. Das heißt das Paket und das Profil, in dem es läuft, denn eine App im Arbeitsprofil ist ein anderer Benutzer als dieselbe App im persönlichen Profil. Das heißt das Ziel: Host, Port und Protokoll, nicht ein Dienstname. Das heißt der DNS-Pfad, der diesen Namen auflöst, und es heißt, was geschehen soll, wenn der Tunnel nicht verfügbar ist.

Aufgeschrieben hat die Richtlinie für das Beispiel vier Zeilen: Die Arbeits-App darf den Arbeitsdienst erreichen; sie darf sonst nichts erreichen; andere Apps bleiben unverändert; ohne Tunnel wird die Arbeits-App abgelehnt, statt auf einen direkten Weg zurückzufallen. Jede Zeile hat einen Eigentümer, und es ist nicht überall derselbe.

Schritt 1: was das Telefon selbst durchsetzen kann

Eine Android-Firewall ohne Root ist ein VpnService, der Verkehr lokal abgreift, auch wenn dahinter kein entfernter Tunnel steht. Android erlaubt einen aktiven VPN-Dienst pro Benutzerprofil, daher kettet sich eine zweite Firewall-App nicht hinter die erste. Sie ersetzt sie, und die Schnittstelle, die die erste App gefiltert hat, verschwindet.

Deshalb ergibt eine Firewall neben einem VPN-Client selten die Kombination, die Leute erwarten. Startet die Firewall und trennt sich das VPN, wurde nichts kombiniert; die beiden haben die Plätze getauscht. Ein Schnittstellentausch ist keine Zusammenarbeit, und das Symptom ist ein Tunnel, der jedes Mal abfällt, wenn die andere App geöffnet wird.

Unterstützte Anordnungen gibt es: Filterung, die im bereits genutzten VPN-Client eingebaut ist, verwaltete Plattformsteuerung über einen Geräterichtlinien-Controller oder ein Arbeitsprofil, oder eine Architektur, die der Anbieter dokumentiert. Alles andere ist ein Experiment, das nach jedem App-Update erneut geprüft werden muss.

Schritt 2: was das Gateway durchsetzen kann

Sobald der Verkehr am fernen Ende entschlüsselt ist, kann das Gateway weitergeleitete Pakete auf genehmigte Adressen, Dienste oder authentifizierte VPN-Identitäten beschränken. Das ist echte Durchsetzung für alles, was dort hinausgeht, und der richtige Ort, um den Zugang zu privaten Subnetzen zu begrenzen.

Was es nicht erhält, ist die App-Identität des Telefons, die an jedem gewöhnlichen IP-Paket hängt. Mehrere Apps, die sich eine Tunneladresse teilen, sind für das Gateway ein Subjekt, es sei denn, das Design gibt ihnen getrennte Adressen oder getrennte authentifizierte Identitäten. Eine Regel pro Benutzer am Gateway ist daher keine Regel pro App auf dem Telefon, wie die Verwaltungskonsole es auch nennt.

Schritt 3: auflisten, was nie ankommt

Eine vom VPN ausgenommene App, die ein Gerät in der Nähe kontaktiert, erreicht das Gateway nie, also kann eine Ausgangs-Firewall ein Paket nicht ablehnen, das sie nie erhält. Dasselbe gilt für einen unbeabsichtigten direkten Weg während eines Ausfalls und für eingehende Exposition im lokalen Zugangsnetz. Das sind lokale Grenzen per Definition.

Das Umgekehrte gilt ebenso: Eine lokale Regel, die eine Verbindung erlaubt, gewährt keinen Zugang über die ACL des privaten Netzes am Gateway. Eine Anfrage kann beiden Grenzen unterliegen, und eine zu erfüllen sagt nichts über die andere.

Schritt 4: jede Regel einem Pfad zuordnen

Legen Sie die Entscheidung in eine Tabelle, bevor Sie irgendetwas konfigurieren, denn die leeren Zellen sind der Ort, an dem Entwürfe scheitern.

Die tragfähige Form sind zwei Grenzen mit zwei Aufgaben. Eine lokale app-bewusste Grenze regelt das Verhalten des Telefons, einschließlich des direkten Rückfalls, und eine Gateway-Grenze regelt entfernte Ressourcen. Die Gateway-Seite kann den Arbeitsdienst erlauben und jedes andere private Subnetz ablehnen, während die Richtlinie auf der Telefonseite selbst über einen direkten Weg entscheidet, den die App sonst nehmen könnte.

Schritt 5: den Transport am Leben halten, dann prüfen

Welche lokale Richtlinie Sie auch wählen, sie muss den Transport erlauben, der das VPN aufbaut und hält. Wird dieser Transport blockiert, bleibt das Telefon ohne Tunnel und ohne Richtlinie, was nichts zusammenhängend durchsetzt und schwer zu diagnostizieren ist, weil die App einfach kein Netz hat.

Prüfen Sie dann jede Zeile des ursprünglichen Satzes statt des Gesamteindrucks: Die Arbeits-App erreicht den Arbeitsdienst, dieselbe App wird an einem anderen Ziel abgelehnt, eine Nicht-Arbeits-App verhält sich wie zuvor, und bei gestopptem Tunnel fällt die Arbeits-App nicht auf eine direkte Verbindung zurück. Prüfen Sie den DNS-Pfad getrennt, denn privates DNS oder ein verschlüsselter Resolver kann einen Filter umgehen, der nur Adressen prüft.

Lässt sich einer dieser Schritte auf dem Telefon nicht erfüllen, ist die Anforderung eine Architekturfrage und keine Firewall-Einstellung. Die Richtlinie zwischen einem Gerät, das Sie kontrollieren, und einem Gateway, das Sie kontrollieren, aufzuteilen, ist meist die ehrliche Antwort, und die Android-Dokumentation zur VPN-Konnektivität ist der Ort, um zu bestätigen, was die Plattform einem einzelnen Dienst erlaubt und was nicht.