Android: Always-On und Sperre ohne VPN — das richtige Paar wählen

Always-On verbindet neu, Blockieren ohne VPN verweigert jeden Ausweg, und das eine einzuschalten schaltet das andere nicht ein. Welches Paar Sie brauchen, hängt davon ab, wem das Gerät gehört, welche Apps der Tunnel abdeckt und was vor dem Entsperren geschieht.

Zwei Schalter mit unterschiedlichen Versprechen

Always-On verspricht Beständigkeit und startet den Dienst nach einem Absturz neu; Blockieren verspricht Abschottung: ohne Tunnel hat der abgedeckte Verkehr keinen Weg nach draußen.

Der dritte Faktor ist der App-Umfang, der beim Client oder der Verwaltungsrichtlinie liegt, nicht bei den Systemschaltern; Blockieren ohne Entscheidung zum Umfang ergibt eine Richtlinie, die weiter oder enger als nötig ist.

Entscheidung eins: verwaltetes Gerät oder Nutzereinstellung?

Auf einem verwalteten Gerät hält die Richtlinie Always-On und Sperre, der lokale Schalter kann fehlen; ändern Sie die Anforderung in der Richtlinie, nicht am Endgerät.

Auf einem privaten Gerät entscheidet der Nutzer, ob er offline bleibt, wenn der Tunnel fehlt; Blockieren ist ein Tausch von Verfügbarkeit, und ein fehlender Schalter rechtfertigt kein Rooten.

Der Umfang gilt je Profil, nicht je Gerät: Android erlaubt ein aktives VPN pro Nutzerprofil.

Eine Sperre im Arbeitsprofil sagt nichts über die private Seite, und ein getesteter Kontext validiert den anderen nicht.

Entscheidung zwei: alles blockieren oder einzelne Apps ausnehmen?

Ausnahmen je App im Sperrmodus werden oft falsch verstanden: Laut Android können ausgenommene Apps die Verbindung verlieren, statt still das normale Netz zu nutzen, eine Ausnahme ist also keine Internet-Erlaubnis.

Entscheiden Sie bewusst: allen abgedeckten Verkehr blockieren und dunkle ausgenommene Apps akzeptieren, oder Sperre aus und Rückfall akzeptieren; muss eine App immer verbunden sein, ist der Sperrmodus das falsche Werkzeug.

Entscheidung drei: was vor dem Entsperren und an einem Portal geschieht?

Bei den meisten Clients steht der Tunnel erst nach dem Entsperren, die ersten Momente nach dem Start sind also eine Lücke, kein Fehler; bestätigen Sie das für Ihren Client.

Captive Portale sind der andere Rand: Ein Hotel- oder Flughafennetz braucht eine nicht authentifizierte Browsersitzung, und eine harte Sperre kann die Anmeldung unmöglich machen; die tragfähige Antwort ist ein genehmigter Wiederherstellungsablauf mit Auslöser, Höchstdauer, Vergaberecht und der Prüfung, dass die Durchsetzung von selbst zurückkehrt.

Die Plattformdokumentation zu Android-VPN-Clients beschreibt Always-On, Sperre, Ausnahmen je App und die Regel eines VPNs pro Profil; lesen Sie sie, bevor Sie aus dem Gedächtnis planen.

Testen Sie den Offline-Zustand und schreiben Sie dann die Abnahmezeile

Nutzen Sie harmlosen Verkehr und den unterstützten Ausfalltest: normale Verbindung, Verlust des Tunnels, Wiederherstellung und Neustart vor dem Entsperren, und notieren Sie, ob die App wie vorgesehen blockte.

Prüfen Sie Ressource und Resolver, nicht das Symbol, und testen Sie ein Gerät hinter dem Handy getrennt, denn die Richtlinie des Handys richtet keine Weiterleitung für Hotspot-Clients ein.

Die Abnahmezeile ist konkret und prüfbar: die vorgesehene App im vorgesehenen Profil erreicht den freigegebenen Tunnel und bleibt gesperrt, wenn sie es nicht kann. Bevor Sie sie unterschreiben:

• Always-On und Sperre sind dort eingerichtet, wo die Plattform sie unterstützt, und der Eigentümer jeder Einstellung ist bekannt.
• Der App-Umfang ist bewusst gewählt und Sie haben bestätigt, was mit ausgenommenen Apps im Sperrmodus geschieht.
• Die Lücke vor dem Entsperren und der Captive-Portal-Ablauf sind entschieden, nicht entdeckt.
• Der Ausfalltest lief auf der Geräteklasse, die Sie tatsächlich ausrollen.