Android: Always-On en blokkering zonder VPN — kies het juiste paar

Always-On en blokkering zonder VPN zijn twee instellingen en de een aanzetten zet de ander niet aan. Het juiste paar hangt af van wie het apparaat bezit, welke apps de tunnel dekt en wat er gebeurt voor het ontgrendelen.

Twee schakelaars met verschillende beloftes

Always-On belooft volharding en herstart de dienst als die wegvalt; blokkering belooft insluiting: zonder tunnel heeft het gedekte verkeer geen weg naar buiten.

De derde factor is het bereik per app, dat bij de client of het beheerbeleid hoort, niet bij de twee systeemschakelaars; blokkeren zonder besluit over het bereik levert beleid op dat breder of smaller is dan nodig.

Eerste beslissing: beheerd apparaat of gebruikersinstelling?

Op een beheerd apparaat houdt het beleid Always-On en vergrendeling, en de lokale schakelaar kan ontbreken; wijzig de eis in het beleid, niet op het apparaat.

Op een persoonlijk apparaat kiest de gebruiker of hij offline accepteert als de tunnel ontbreekt; blokkering is een ruil in beschikbaarheid, en een ontbrekende schakelaar is geen reden voor root.

Het bereik is per profiel, niet per apparaat: Android staat één actieve VPN per gebruikersprofiel toe.

Een blokkade in het werkprofiel zegt niets over de persoonlijke kant, en het testen van de ene context bevestigt de andere niet.

Tweede beslissing: alles blokkeren of enkele apps uitsluiten?

Uitsluitingen per app in blokkeermodus worden vaak omgekeerd begrepen: volgens Android kunnen uitgesloten apps de verbinding verliezen in plaats van stil het gewone net te gebruiken, dus een uitsluiting is geen internettoestemming.

Kies bewust: blokkeer al het gedekte verkeer en accepteer dat uitgesloten apps donker blijven, of zet blokkering uit en accepteer de terugvalroute; moet één app altijd verbonden zijn, dan is blokkering het verkeerde instrument.

Derde beslissing: wat gebeurt er voor het ontgrendelen en bij een portaal?

Bij de meeste clients staat de tunnel pas als de gebruiker het apparaat ontgrendelt, dus de eerste momenten na het opstarten zijn een gat, geen storing; bevestig dat voor de client die je uitrolt.

Captive-portalen zijn de andere rand: een hotel- of luchthavennetwerk vraagt een niet-geauthenticeerde browsersessie en een harde blokkade kan inloggen onmogelijk maken; het ondersteunde antwoord is een goedgekeurde herstelstroom met trigger, maximale duur, wie hem geeft en de controle dat de handhaving vanzelf terugkeert.

De documentatie over Android VPN-clients behandelt Always-On, blokkering, uitsluitingen per app en de regel van één VPN per profiel; lees die voordat je uit het geheugen ontwerpt.

Test de offline status en schrijf dan de acceptatieregel

Gebruik onschadelijk verkeer en de door de client ondersteunde fouttest: gewone verbinding, verlies van de tunnel, herstel en herstart voor het ontgrendelen, en noteer of de app blokkeerde zoals bedoeld.

Controleer de bron en de resolver, niet het pictogram, en test een apparaat achter de telefoon apart, want het beleid van de telefoon stelt geen doorsturing in voor hotspot-clients.

De acceptatieregel is concreet en testbaar: de bedoelde app in het bedoelde profiel bereikt de goedgekeurde tunnel en blijft in de vereiste geblokkeerde staat wanneer dat niet kan. Voordat je tekent:

• Always-On en blokkering zijn ingesteld waar het platform ze ondersteunt, en de eigenaar van elke instelling is bekend.
• Het app-bereik is bewust en je hebt bevestigd wat er met uitgesloten apps in blokkeermodus gebeurt.
• Het gat voor het ontgrendelen en de captive-portaalstroom zijn besloten, niet ontdekt.
• De fouttest is uitgevoerd op de apparaatklasse die je echt uitrolt.