Le tunnel fractionné pour les clients de point d’accès n’est pas une exclusion par application

Deux exigences qui sonnent équivalentes ne le sont pas : « exclure cette application du VPN » et « envoyer cette seule destination hors du VPN pour l’ordinateur portable sur mon point d’accès ». La première change la façon dont une socket du téléphone choisit un réseau. La seconde doit changer une décision de transfert pour un paquet arrivé d’un autre appareil après que le téléphone l’a déjà accepté. Confondre les deux, c’est ce qui laisse un client de point d’accès avec une exception qui n’a jamais visé que le navigateur du téléphone lui-même.

Deux sous-systèmes possèdent les deux questions

Android sépare les réseaux d’applications et le partage de connexion. Les sockets des applications sont affectées à un réseau par la pile de connectivité, et une application VPN décide lesquelles de ses propres sockets entrent dans le tunnel. Les paquets transférés d’un client connecté sont traités par le sous-système de partage de connexion, qui demande à netd des routes, des règles de politique et de la traduction sur l’interface descendante.

L’exclusion par application est évaluée lorsqu’une application ouvre une socket. Un paquet transféré n’atteint jamais ce contrôle, parce qu’il ne provient pas d’une socket d’application de cet appareil. C’est toute la raison pour laquelle les deux réglages ne peuvent pas se substituer l’un à l’autre, et ce n’est un défaut ni de l’un ni de l’autre.

Ce que l’exclusion par application change réellement

Un constructeur de VpnService peut nommer les paquets qui restent hors du tunnel avec addDisallowedApplication, ou nommer les seuls paquets autorisés à l’intérieur avec addAllowedApplication. Ces applications ouvrent alors des sockets sur le réseau sous-jacent tandis que le VPN continue de posséder la route par défaut pour tout le reste.

La portée est précise : les sockets propres du paquet, sur cet appareil, tant que le tunnel est actif. Elle ne dit rien du trafic transféré, rien d’un second appareil et rien des paquets que le système envoie au nom du partage de connexion.

Ce n’est pas non plus un contrôle de destination. Exclure un navigateur exclut chaque adresse que ce navigateur atteint, y compris celle que vous vouliez garder dans le tunnel. Quand l’exigence nomme une destination plutôt qu’une application, le sélecteur d’applications est le mauvais outil par construction.

À quoi ressemble un paquet partagé pour le téléphone

Le paquet du client arrive sur l’interface du point d’accès avec une adresse source privée attribuée par le téléphone, disons 192.168.43.20, et une destination publique. Pour le transférer, le téléphone a besoin d’une route vers un lien montant et d’une règle de traduction pour que les réponses retrouvent leur chemin, car l’adresse privée du client n’a aucun sens sur le réseau cellulaire.

Android exprime cela avec des règles de politique qui sélectionnent une table de routage, et netd reconstruit les tables et règles concernées quand les réseaux et les VPN changent. Un numéro de table, une priorité de règle ou un nom d’interface copiés d’un message de forum, ou du même modèle dans une version plus ancienne, n’établissent pas une propriété durable. Cette reconstruction est aussi pourquoi une règle écrite à la main peut fonctionner une heure puis s’arrêter après la reconnexion suivante.

La politique dont une exception de point d’accès a réellement besoin

Écrivez la décision sous forme de source, de destination et de chemin prévu avant de toucher à une règle. La forme minimale pour une destination approuvée ressemble à ceci :

Les deux sens doivent être complets. La branche directe a besoin d’une route utilisable par le lien montant cellulaire qui se trouve être actuel ; la branche VPN a besoin de la route du tunnel plus l’autorisation de transférer. Toute traduction de source doit correspondre à la sortie choisie, parce que le NAT appliqué sur une interface de tunnel présente l’adresse du tunnel et non celle du cellulaire, et le chemin de retour ne concorde alors pas avec le chemin aller.

Les réponses doivent atteindre le même client descendant via un état suivi ou une route explicite, et un compteur de paquets sortants n’en prouve rien. Gardez aussi le transport extérieur du VPN hors de la portée de l’exception, sinon les paquets porteurs du tunnel héritent d’une politique écrite pour une requête web d’un client.

Une adresse capturée n’est pas une destination

Une seule adresse IPv4 lue dans un navigateur est un instantané. Les grands services répondent en anycast ou depuis un ensemble tournant d’adresses de bord, beaucoup sont en double pile, et un flux de connexion peut toucher des hôtes d’authentification et de télémétrie que la page n’affiche jamais. Une exception bâtie autour de l’adresse que vous avez vue par hasard casse la prochaine fois que le service rééquilibre.

Utilisez les adresses documentées par le propriétaire du service, ou une plage qu’il publie, et tenez compte des deux familles d’adresses. Si l’exigence ne peut pas être exprimée comme un ensemble stable, c’est probablement une question de politique pour le service et non une astuce de routage sur un téléphone.

Vérifiez depuis le côté descendant

Trois contrôles, dans cet ordre : le service choisi depuis l’ordinateur portable, une destination ordinaire qui doit rester dans le VPN et une application du téléphone qui doit rester intacte. Répétez ensuite après une reconnexion et après un changement de lien montant, car c’est alors que les tables de politique sont reconstruites.

Si l’implémentation de partage du téléphone ne peut pas tenir ce contrat lors d’une reconnexion, déplacez la politique sélective vers un routeur descendant pris en charge plutôt que d’accumuler des règles root sur l’appareil. Un routeur peut exprimer une correspondance de source et de destination avec un propriétaire stable, et la documentation du module de partage de connexion est la bonne référence pour ce que le téléphone fait réellement.