Une app cochée dans OpenVPN ? C’est la base de la liste qui décide
Le même paquet coché signifie inclure ou exclure selon la base de la liste. Choisissez d’abord inclusion seule, reconnectez-vous, puis testez tout le flux de travail.
La case ressemble à toute la décision, et sous Android elle ne l’est pas. Le même paquet coché signifie « seule cette app utilise le VPN » avec une base d’inclusion seule et « cette app contourne le VPN » avec une base d’exclusion des éléments sélectionnés. Les gens installent un client, trouvent une liste intitulée Applications autorisées, cochent le seul paquet qui les intéresse et repartent avec une politique qui fait l’inverse. Changer de client aide rarement ; choisir la base avant de toucher la liste aide.
La base est la politique, pas la case
Avec le VpnService d’Android, un client configure le routage par application avec addAllowedApplication ou addDisallowedApplication. Le premier limite le tunnel aux paquets listés, le second fait passer tout sauf eux par le tunnel. Les clients enveloppent les deux dans une interface qui peut sembler presque identique, et certains nomment la section d’après la liste plutôt que d’après le mode, si bien que le titre de la section seul ne peut pas vous dire quelle base est active.
Lisez le contrôle de mode au-dessus de la liste, pas le titre. Dans le client OpenVPN for Android d’origine, la liste des applications autorisées dispose d’une base d’inclusion seule et d’une base d’exclusion des éléments sélectionnés, et une compilation de marque peut formuler les deux différemment tout en conservant les mêmes deux comportements. Une capture d’un autre client, ou d’une version plus ancienne du même, ne prouve rien sur le mode dans lequel vous êtes.
| What the client shows | What a checked app gets |
|---|---|
| Allowed apps, include-only baseline | The app uses the tunnel; unchecked apps do not |
| Allowed apps, exclude-selected baseline | The app bypasses the tunnel; everything else uses it |
| No list configured | Client or profile default, commonly all apps |
Ce tableau, c’est tout le mythe. Cocher l’app est une affirmation sur un paquet ; la base décide si l’affirmation est « incluez-le » ou « excluez-le ».
D’abord le mode, ensuite le paquet
Travaillez dans cet ordre, car une sélection faite sous une base peut survivre à un changement de mode et inverser silencieusement son effet :
- Identifiez le vrai paquet et s’il s’agit de la copie du profil personnel ou professionnel.
- Ouvrez les réglages de sélection d’applications pour le profil VPN exact avec lequel vous vous connectez.
- Définissez la base dont le sens est « seules les apps sélectionnées utilisent le VPN ».
- Incluez le paquet voulu et laissez les apps sans rapport hors de l’ensemble.
- Reconnectez-vous pour que le client reconstruise l’interface avec la nouvelle liste.
Le profil compte autant que le paquet. Un client peut contenir plusieurs profils, et la sélection par application appartient à celui avec lequel vous vous connectez réellement ; modifier un profil que vous n’utilisez jamais ne change rien. Sur un appareil géré, le profil professionnel est un utilisateur distinct avec sa propre copie de l’app et sa propre politique, donc le fait que l’instance personnelle soit dans le tunnel ne dit rien de l’instance professionnelle.
Reconnectez-vous avant de juger le résultat
VpnService lit les listes d’applications lorsque l’interface du tunnel est établie. Un tunnel en cours ne reprend pas nécessairement une modification de liste, et les clients diffèrent selon qu’ils reconstruisent automatiquement ou attendent que vous vous déconnectiez et reconnectiez.
Si le changement semble ne rien faire, testez la reconnexion avant de douter de la liste. Ensuite, faites une requête neuve plutôt que de recharger une page déjà ouverte : une app qui garde une connexion établie est un mauvais sujet de test, et le résultat observé peut appartenir à l’ancienne interface.
Votre flux de travail peut quitter l’app
Une app peut déléguer à un navigateur pour la connexion, à une visionneuse de documents ou à une cible de partage. Avec une base d’inclusion seule, ces auxiliaires sont hors du tunnel, si bien qu’un flux de travail peut échouer à mi-parcours même si la première app était bien configurée. N’incluez l’auxiliaire que si le flux de travail en a vraiment besoin, et ajoutez-le délibérément au lieu de le découvrir pendant une démo.
La sélection par application ne remplace pas non plus la politique de routage propre à la connexion. Le profil doit toujours porter les préfixes de destination et les familles d’adresses que l’app utilise, et la passerelle doit toujours autoriser le service. Une app correctement listée avec une destination injoignable ressemble à une liste mal configurée.
Testez les deux côtés, puis consignez la politique
Testez une requête neuve dans l’app incluse et une dans une app censée rester dehors. Comparez l’adresse de sortie et l’accès à une ressource privée, puis répétez après une reconnexion. Si votre organisation utilise la politique Android de blocage des connexions sans VPN, une app exclue peut être bloquée d’emblée au lieu d’aller directement ; c’est la politique qui fonctionne, pas une panne à contourner.
Consignez le mode, les noms de paquets avec leur profil, les apps qui doivent contourner, les familles d’adresses que porte le tunnel et ce qui doit se passer quand le tunnel est coupé. Si le client ne peut pas exprimer proprement le flux de travail, choisissez un ensemble d’apps approuvé plus large ou une politique de profil géré plutôt que de modifier des règles de pare-feu au niveau racine, ce qui ne fait pas partie du mécanisme par application pris en charge par Android.