Android: Always-On och blockering utan VPN — välj rätt par

Always-On och blockering utan VPN är två inställningar och att slå på den ena slår inte på den andra. Rätt par beror på vem som äger enheten, vilka appar tunneln täcker och vad som händer före upplåsningen.

Två brytare med olika löften

Always-On lovar varaktighet och startar om tjänsten när den faller; blockeringen lovar instängning: utan tunnel har den täckta trafiken ingen väg ut.

Den tredje faktorn är omfånget per app, som hör till klienten eller hanteringspolicyn, inte de två systembrytarna; blockering utan beslut om omfång ger en policy som är bredare eller snävare än kravet.

Första beslutet: hanterad enhet eller användarinställning?

På en hanterad enhet håller policyn Always-On och låsningen, och den lokala brytaren kan saknas; ändra kravet i policyn, inte på enheten.

På en personlig enhet väljer användaren om hen accepterar att vara utan nät när tunneln saknas; blockering är ett byte av tillgänglighet, och en saknad brytare är inget skäl att roota.

Omfånget är per profil, inte per enhet: Android tillåter en aktiv VPN per användarprofil.

En blockering i arbetsprofilen säger inget om den personliga sidan, och att testa en kontext validerar inte den andra.

Andra beslutet: allt blockerat eller några appar undantagna?

Undantag per app i blockeringsläge förstås ofta bakvänt: enligt Android kan undantagna appar tappa anslutningen i stället för att tyst använda det vanliga nätet, så ett undantag är inget tillstånd till internet.

Välj medvetet: blockera all täckt trafik och acceptera att undantagna appar blir mörka, eller slå av blockeringen och acceptera reservvägen; måste en app alltid vara ansluten är blockering fel verktyg.

Tredje beslutet: vad händer före upplåsningen och vid en portal?

Hos de flesta klienter är tunneln inte uppe förrän användaren låser upp enheten, så de första ögonblicken efter start är en lucka, inte ett fel; bekräfta det för klienten du rullar ut.

Captive-portaler är den andra kanten: ett hotell- eller flygplatsnät kräver en oautentiserad webbläsarsession och en hård blockering kan göra inloggning omöjlig; det stödda svaret är ett godkänt återställningsflöde med utlösare, maximal varaktighet, vem som ger det och kontrollen att upprätthållandet kommer tillbaka av sig själv.

Dokumentationen om Android VPN-klienter täcker Always-On, blockering, undantag per app och regeln om en VPN per profil; läs den innan du designar ur minnet.

Testa läget utan nät och skriv sedan acceptansraden

Använd ofarlig trafik och klientens stödda feltest: vanlig anslutning, förlust av tunneln, återhämtning och omstart före upplåsning, och notera om appen blockerade som den skulle.

Kontrollera resursen och resolvern, inte ikonen, och testa en enhet bakom telefonen separat, eftersom telefonens policy inte upprättar vidarebefordran för hotspot-klienter.

Acceptansraden är konkret och testbar: den avsedda appen i den avsedda profilen når den godkända tunneln och stannar i det krävda blockerade läget när den inte kan. Innan du signerar:

• Always-On och blockering är inställda där plattformen stöder dem, och ägaren av varje inställning är känd.
• Appomfånget är medvetet och du har bekräftat vad som händer med undantagna appar i blockeringsläge.
• Luckan före upplåsningen och captive-portalflödet är beslutade, inte upptäckta.
• Feltestet kördes på den enhetsklass du faktiskt rullar ut.