Always-On og blokkering uten VPN er to innstillinger, og å aktivere den ene aktiverer ikke den andre. Riktig par avhenger av hvem som eier enheten, hvilke apper tunnelen dekker og hva som skjer før opplåsing.

To brytere med forskjellige løfter

Always-On lover vedvarende drift og restarter tjenesten når den faller; blokkering lover innesperring: uten tunnel har den dekkede trafikken ingen vei ut.

Den tredje faktoren er omfanget per app, som hører til klienten eller administrasjonspolicyen, ikke de to systembryterne; blokkering uten en beslutning om omfang gir en policy som er bredere eller smalere enn kravet.

Første beslutning: administrert enhet eller brukerinnstilling?

På en administrert enhet styrer policyen Always-On og låsing, og den lokale bryteren kan mangle; endre kravet i policyen, ikke på enheten.

På en personlig enhet velger brukeren om han godtar å være uten nett når tunnelen mangler; blokkering er en byttehandel om tilgjengelighet, og en manglende bryter er ikke grunn til å roote.

Omfanget er per profil, ikke per enhet: Android tillater én aktiv VPN per brukerprofil.

Blokkering i arbeidsprofilen sier ingenting om den personlige siden, og testing av én kontekst validerer ikke den andre.

Andre beslutning: alt blokkert eller noen apper unntatt?

Unntak per app i blokkeringsmodus forstås ofte baklengs: ifølge Android kan unntatte apper miste tilkoblingen i stedet for stille å bruke det vanlige nettet, så et unntak er ikke tillatelse til internett.

Velg bevisst: blokker all dekket trafikk og godta at unntatte apper blir mørke, eller slå av blokkering og godta reserveveien; må én app alltid være tilkoblet, er blokkering feil verktøy.

Tredje beslutning: hva skjer før opplåsing og ved en portal?

Hos de fleste klienter er ikke tunnelen oppe før brukeren låser opp enheten, så de første øyeblikkene etter oppstart er et hull, ikke en feil; bekreft det for klienten du ruller ut.

Captive-portaler er den andre kanten: et hotell- eller flyplassnett krever en uautentisert nettleserøkt, og en hard blokkering kan gjøre innlogging umulig; det støttede svaret er en godkjent gjenopprettingsflyt med utløser, maksimal varighet, hvem som kan gi den og kontrollen av at håndhevelsen kommer tilbake av seg selv.

Dokumentasjonen om Android VPN-klienter dekker Always-On, blokkering, unntak per app og regelen om én VPN per profil; les den før du designer etter hukommelsen.

Test tilstanden uten nett og skriv deretter akseptlinjen

Bruk ufarlig trafikk og klientens støttede feiltest: vanlig tilkobling, tap av tunnelen, gjenoppretting og omstart før opplåsing, og noter om appen blokkerte som den skulle.

Kontroller ressursen og resolveren, ikke ikonet, og test en enhet bak telefonen separat, for telefonens policy etablerer ikke videresending for hotspot-klienter.

Akseptlinjen er konkret og testbar: den tiltenkte appen i den tiltenkte profilen når den godkjente tunnelen og blir i den påkrevde blokkerte tilstanden når den ikke kan. Før du signerer:

  • Always-On og blokkering er satt opp der plattformen støtter dem, og eieren av hver innstilling er kjent.
  • App-omfanget er bevisst, og du har bekreftet hva som skjer med unntatte apper i blokkeringsmodus.
  • Hullet før opplåsing og captive-portal-flyten er besluttet, ikke oppdaget.
  • Feiltesten ble kjørt på enhetsklassen du faktisk ruller ut.

Relaterte artikler