Votre coupe-circuit bloquera-t-il l’application que vous avez exclue du tunnel ?

Coupe-circuit activé, une application délibérément exclue du tunnel, et les deux exigences se contredisent désormais. L’une dit que rien ne doit sortir sauf par le tunnel, l’autre dit que ce programme doit passer en direct. Chaque client résout ce conflit différemment, et la page de réglages explique rarement quelle règle l’emporte. Écrivez la politique par application avant de faire confiance à une étiquette.

Deux politiques, une machine

Un coupe-circuit est une promesse sur la panne : quand le tunnel ne protège pas le trafic, le trafic s’arrête. Le tunnel divisé est une promesse sur la sélection : ces programmes ou destinations utilisent le tunnel, et les autres non. La seconde promesse crée du trafic sur lequel la première doit statuer. Aucune des deux n’est fausse ; elles ont simplement été écrites par des personnes différentes pour des menaces différentes.

Trois issues sont possibles et une seule correspond à ce que le déploiement voulait. L’application exclue peut rester en direct pendant une panne, ce qui respecte la division et casse le coupe-circuit. Elle peut être bloquée avec tout le reste, ce qui respecte le coupe-circuit et casse la division. Ou elle peut n’être bloquée que parfois, selon la manière dont la plateforme évalue la règle après la disparition d’une interface. C’est ce dernier cas qui produit des tickets.

Écrivez la liste des applications avant la règle

Listez les programmes qui doivent utiliser le tunnel, ceux qui doivent passer en direct, et les noms ou destinations qui ne doivent jamais figurer sur l’une ou l’autre liste. Ajoutez séparément le comportement du résolveur et le côté IPv6, car tous deux peuvent suivre une politique différente de celle du trafic des pages.

Les règles par application correspondent généralement à un exécutable ou à un paquet, pas à un profil à l’intérieur. Un profil de navigateur, une fenêtre privée et une extension ne portent aucune identité réseau propre, ils héritent donc de ce que le processus a reçu. Un processus auxiliaire lancé par ce navigateur peut ne pas hériter du tout de la même règle.

Deux listes sont nécessaires, pas une : ce que le tunnel doit transporter et ce qui ne doit jamais voyager hors de lui pour quelque raison que ce soit. Une application présente sur les deux est un conflit d’exigences et non un détail d’implémentation, et il faut le trancher avant de configurer le client.

Ce que fait le client pendant une panne

Certaines implémentations bloquent les applications exclues pendant une panne et rétablissent leur accès à la reconnexion. D’autres conservent la voie directe en permanence, ce qui est cohérent avec la division et plus faible comme propriété de sécurité. Un verrouillage au niveau de la plateforme peut annuler entièrement la sélection par application du client. Cette différence n’est pas cosmétique, car elle décide si l’application exclue est une exception de politique ou un trou.

Le VPN toujours actif d’Android avec l’option de bloquer les connexions sans VPN est le cas le plus clair, car la plateforme impose le verrouillage et non le client, et un paquet exclu est bloqué avec tout le reste tant que le tunnel est coupé. Un client de bureau qui applique des exclusions par application dans son propre pilote laisse généralement le processus exclu sur l’interface physique, car il n’a jamais possédé le trafic de ce processus. Les deux comportements sont défendables et un seul correspond à une exigence qui dit que l’application exclue doit rester utilisable. Demandez quel composant impose la règle avant d’interpréter le résultat.

Lisez le comportement du système d’exploitation qui est devant vous, pas le réglage du même nom ailleurs. Les API d’application diffèrent, et une case à cocher peut signifier des choses strictement différentes sur un bureau et sur un téléphone. La version compte aussi, car le contrôle de verrouillage a changé d’écran au fil des versions d’Android, et une liste d’exclusions côté client n’est pas le même contrôle qu’un verrouillage de plateforme.

Trois moments : tunnel actif, tunnel coupé, reconnexion

Utilisez des requêtes inoffensives à trois moments : pendant que le tunnel fonctionne, pendant la panne qui vous intéresse et après la reconnexion. Un seul résultat de navigateur ne peut pas établir le comportement de l’application exclue.

curl -sS --max-time 8 https://api.ipify.org
curl -sS --max-time 8 --interface tun0 https://api.ipify.org
dig +short example.com

L’adresse de sortie montre quel chemin a été pris, et le test d’interface explicite montre ce qui se passe quand le tunnel est la seule sortie disponible. Notez le résultat attendu à côté de chaque ligne avant d’en exécuter une seule, sinon la sortie sera interprétée après coup.

Si une application exclue passe hors ligne, examinez la priorité des politiques avant d’ajouter une autorisation large dans le pare-feu, car ce correctif détruit la distinction que vous testiez. Si elle reste en direct, confirmez qu’il s’agissait de l’exception documentée et non d’un repli accidentel. Pour une exigence stricte sur tout l’appareil, raccourcissez la liste des exceptions jusqu’à ce qu’elle puisse être testée à la main.