Interrupteur par application ou verrouillage de tout l'appareil : ce qui change

Un interrupteur par application ressemble au choix prudent : seul le client de travail perd son réseau quand le tunnel tombe, et tout le reste continue de fonctionner. Puis quelqu'un remarque que le navigateur personnel a quand même chargé une page, que l'assistant de synchronisation fourni avec la même suite continuait de réessayer et qu'un nom en cache se résolvait toujours vers une adresse qui n'a jamais touché le tunnel. L'étiquette de la fonction et l'ensemble des connexions qu'elle protège réellement sont deux choses différentes. Déterminez d'abord l'ensemble protégé, car c'est lui qui décide si l'application par application ou le verrouillage de tout l'appareil est la description honnête.

Commencez par l'ensemble, pas par l'étiquette

Une politique par application protège les applications sélectionnées. Un verrouillage d'appareil vise une frontière réseau plus large, généralement avec des exceptions documentées pour l'impression locale, le trafic de gestion ou les portails captifs. Aucune des deux étiquettes n'est complète tant que vous ne pouvez pas répondre à trois questions : ce qui arrive aux applications exclues, ce qui arrive aux assistants que ces applications lancent et ce qui arrive aux connexions ouvertes pendant que la protection n'est pas disponible.

Écrivez ces réponses avant de toucher à un réglage du client. Si l'exigence est "ce client de paie ne doit jamais parler à internet hors du tunnel, et mon navigateur le peut", l'ensemble est petit et l'application par application convient. Si l'exigence est "rien sur cet appareil n'atteint internet sans protection, sauf le service de mise à jour", aucune politique par application ne le produira, car les applications que vous n'avez pas nommées sont le problème.

L'application par application correspond à des identifiants, pas à des noms de programmes

Android expose le VPN par application au moyen de paquets, et sa documentation VpnService décrit comment cela interagit avec le fonctionnement permanent et le blocage. iOS configure le VPN par application au moyen d'un profil de gestion et correspond par application ou par domaine. Windows et Linux n'ont aucune route par processus, donc la même idée est approchée par une règle de pare-feu limitée à un programme ou par une règle qui correspond à l'utilisateur propriétaire.

La frontière est l'identifiant, et les identifiants sont faciles à contourner. Une application qui remet une URL au navigateur du système, ou ouvre un document dans une visionneuse, passe dans un processus que votre politique n'a jamais nommé. Une option de terminer à la chute n'est pas non plus un filtre de paquets : elle tue l'application que vous avez configurée, tandis qu'un processus enfant, un ouvrier de file ou un onglet de navigateur peuvent maintenir une socket existante en vie.

Le verrouillage couvre ce qu'une politique par application ne voit pas

Le verrouillage de tout l'appareil supprime le choix. Chaque paquet sortant qui n'appartient pas au tunnel est rejeté, y compris le trafic de processus que votre politique d'applications n'a jamais connus. Sous Android, c'est le VPN permanent combiné au réglage de blocage des connexions, et l'application se fait dans le système, pas dans la fenêtre du client. Sur un bureau, c'est une règle de pare-feu persistante ou une route par défaut pointant vers une passerelle injoignable.

Le coût est que tout le reste s'arrête, donc les exceptions font partie de la conception au lieu d'être une réflexion après coup. Imprimantes locales, découverte de services, connexions aux portails captifs, agents de gestion et mises à jour du système d'exploitation ont chacun besoin d'un trou documenté, car chacun est un chemin qui reste ouvert quand le tunnel est en panne. Le verrouillage n'est aussi solide que l'entrée la plus courte de cette liste.

DNS, IPv6 et assistants en arrière-plan cachent les fuites

Qu'une application protégée ne parvienne pas à résoudre un nom ne prouve pas que les réponses en cache ou le trafic IP direct sont bloqués. Si le résolveur reste joignable hors du tunnel, le nom se résout et la connexion échoue, ce qui ressemble à un interrupteur qui fonctionne et n'en est pas un. Pire, un enregistrement en cache peut pointer vers une adresse que le tunnel ne transporte pas, si bien que la connexion sort directement pendant que l'application signale une erreur VPN.

IPv6 a besoin de sa propre règle sur chaque plateforme qui l'exécute, car une règle de rejet pour v4 ne couvre pas une route v6. Sur mobile, un réglage de DNS privé peut déplacer la résolution dans un canal chiffré que la politique de l'appareil n'inspecte pas. Et les assistants en arrière-plan sont le coupable habituel sur bureau : un processus de mise à jour ou de synchronisation dans la barre d'état démarre avant le client VPN et conserve sa propre connexion, si bien qu'il ne voit jamais la route modifiée.

Testez trois applications et deux transitions

Exécutez chaque ligne deux fois, une fois avec un nom d'hôte et une fois avec une adresse littérale, et une fois de plus en IPv6 si le réseau l'offre. Une réussite signifie que l'application incluse s'est arrêtée, que l'exclue s'est comportée comme vous l'avez écrit et que l'assistant ne s'est pas échappé. Notez le comportement direct que vous avez jugé acceptable, afin que le prochain administrateur distingue une exception délibérée d'une défaillance.

Décrivez ensuite le résultat en une phrase qui nomme les applications et les conditions, par exemple : le client de paie n'a aucune route hors du tunnel, le navigateur est direct par conception et tout le reste s'arrête quand le tunnel est en panne. Si cette phrase est difficile à écrire, la politique reste deux politiques qui se combattent.