Android: Always-On og blokering uden VPN — vælg det rigtige par

Always-On genopretter tunnelen, og blokering uden VPN afviser enhver reservevej; det ene tændes ikke med det andet. Parret afhænger af, hvem der ejer enheden, hvilke apps tunnelen dækker, og hvad der sker før oplåsning.

To kontakter med forskellige løfter

Always-On lover vedholdenhed og genstarter tjenesten efter et nedbrud; blokering lover indhegning: uden tunnel har den dækkede trafik ingen vej ud.

Den tredje faktor er app-omfanget, som hører til klienten eller administrationspolitikken, ikke de to systemkontakter; blokering uden en beslutning om omfang giver en politik, der er bredere eller smallere end kravet.

Første beslutning: administreret enhed eller brugerindstilling?

På en administreret enhed styrer politikken Always-On og låsning, og den lokale kontakt kan mangle; ændr kravet i politikken, ikke på enheden.

På en privat enhed vælger brugeren, om offline er acceptabelt, når tunnelen ikke er der; blokering er en handel med tilgængelighed, og en manglende kontakt er ikke grund til at roote.

Omfanget gælder pr. profil, ikke pr. enhed: Android tillader én aktiv VPN pr. brugerprofil.

En blokering i arbejdsprofilen siger intet om den private side, og en test af én kontekst validerer ikke den anden.

Anden beslutning: alt blokeret eller nogle apps undtaget?

Undtagelser pr. app i blokeringstilstand forstås ofte omvendt: Ifølge Android kan undtagne apps miste forbindelsen i stedet for stille at bruge det normale net, så en undtagelse er ikke tilladelse til internet.

Vælg bevidst: bloker al dækket trafik og accepter, at undtagne apps går i sort, eller slå blokering fra og accepter reservevejen; skal én app altid have forbindelse, er blokering det forkerte værktøj.

Tredje beslutning: hvad sker der før oplåsning og ved en portal?

Hos de fleste klienter er tunnelen ikke oppe, før enheden låses op, så de første øjeblikke efter opstart er et hul, ikke en fejl; bekræft det for den klient, du udruller.

Captive-portaler er den anden kant: et hotel- eller lufthavnsnet kræver en uautentificeret browsersession, og en hård blokering kan umuliggøre login; det understøttede svar er et godkendt genopretningsforløb med udløser, maksimal varighed, hvem der kan give det, og kontrol af, at håndhævelsen vender tilbage af sig selv.

Platformsdokumentationen om Android VPN-klienter dækker Always-On, blokering, undtagelser pr. app og reglen om én VPN pr. profil; læs den, før du designer ud fra hukommelsen.

Test offline-tilstanden, og skriv så acceptlinjen

Brug ufarlig trafik og klientens understøttede fejltest: normal forbindelse, tab af tunnelen, genopretning og genstart før oplåsning, og noter, om appen blokerede som tiltænkt.

Kontroller ressourcen og resolveren, ikke ikonet, og test en enhed bag telefonen separat, for telefonens politik etablerer ikke videresendelse til hotspot-klienter.

Acceptlinjen er konkret og testbar: den tilsigtede app i den tilsigtede profil når den godkendte tunnel og forbliver blokeret, når den ikke kan. Før du skriver under:

• Always-On og blokering er sat op, hvor platformen understøtter dem, og ejeren af hver indstilling er kendt.
• App-omfanget er bevidst, og du har bekræftet, hvad der sker med undtagne apps i blokeringstilstand.
• Hullet før oplåsning og captive-portal-forløbet er besluttet, ikke opdaget.
• Fejltesten blev kørt på den enhedsklasse, du faktisk udruller.