Android : Always-On et blocage sans VPN, choisir la bonne paire

Always-On reconnecte le tunnel et le blocage sans VPN refuse toute issue de secours ; activer l’un n’active pas l’autre. La bonne paire dépend du propriétaire de l’appareil, des applis couvertes par le tunnel et de ce qui se passe avant le déverrouillage.

Deux interrupteurs aux promesses différentes

Always-On promet la persistance et relance le service quand il tombe ; le blocage promet le confinement : sans tunnel, le trafic couvert n’a aucune sortie.

Le troisième facteur est la portée par appli, qui relève du client ou de la politique de gestion, pas des deux interrupteurs système ; bloquer sans décider la portée donne une politique plus large ou plus étroite que le besoin.

Décision un : appareil géré ou réglage utilisateur ?

Sur un appareil géré, la politique tient Always-On et le verrouillage, et l’interrupteur local peut manquer ; changez l’exigence dans la politique, pas sur l’appareil.

Sur un appareil personnel, l’utilisateur choisit d’accepter ou non l’absence de réseau quand le tunnel manque ; le blocage est un échange de disponibilité, et un interrupteur absent ne justifie pas un root.

La portée est par profil, pas par appareil : Android autorise un seul VPN actif par profil utilisateur.

Un blocage dans le profil professionnel ne dit rien du côté personnel, et tester un contexte ne valide pas l’autre.

Décision deux : tout bloquer ou exclure certaines applis ?

Les exclusions par appli en mode blocage se comprennent à l’envers : selon Android, les applis exclues peuvent perdre la connexion au lieu d’utiliser discrètement le réseau normal, donc exclure n’est pas une autorisation d’internet.

Choisissez sciemment : bloquez tout le trafic couvert et acceptez que les applis exclues restent dans le noir, ou coupez le blocage et acceptez le repli ; si une appli doit toujours être connectée, le blocage est le mauvais outil.

Décision trois : que se passe-t-il avant le déverrouillage et sur un portail ?

Chez la plupart des clients, le tunnel n’est pas monté avant le déverrouillage, donc les premiers instants après le démarrage sont un trou, pas une panne ; confirmez-le pour le client déployé.

Les portails captifs sont l’autre bord : un réseau d’hôtel ou d’aéroport exige une session de navigateur non authentifiée et un blocage dur peut rendre la connexion impossible ; la réponse admise est un flux de récupération approuvé avec déclencheur, durée maximale, qui l’accorde et la vérification que l’application revient seule.

La documentation des clients VPN Android couvre Always-On, le blocage, les exclusions par appli et la règle d’un VPN par profil ; lisez-la avant de concevoir de mémoire.

Testez l’état hors ligne, puis écrivez la ligne d’acceptation

Utilisez un trafic anodin et le test de panne pris en charge : connexion normale, perte du tunnel, récupération et redémarrage avant déverrouillage, en notant si l’appli a été bloquée comme prévu.

Vérifiez la ressource et le résolveur, pas l’icône, et testez à part un appareil derrière le téléphone, car la politique du téléphone n’établit pas de transfert pour les clients du point d’accès.

La ligne d’acceptation est précise et testable : l’appli prévue dans le profil prévu atteint le tunnel approuvé et reste bloquée quand elle ne peut pas. Avant de la signer :

• Always-On et le blocage sont configurés là où la plateforme les prend en charge, et le propriétaire de chaque réglage est connu.
• La portée des applis est délibérée et vous avez confirmé ce qui arrive aux applis exclues en mode blocage.
• Le trou avant déverrouillage et le flux de portail captif sont décidés, pas découverts.
• Le test de panne a été fait sur la classe d’appareils que vous déployez réellement.