Les exclusions VPN par application se cassent quand un service partagé récupère les données

Vous excluez une application du VPN et le téléchargement dont elle avait besoin échoue toujours ou, pire, il se met à fonctionner et autre chose d’indépendant s’arrête. La fenêtre visible n’est pas forcément le processus qui ouvre chaque connexion : une application peut confier le travail à un auxiliaire, à un service de transfert en arrière-plan ou à un paquet complètement différent. Une règle par application a donc besoin du modèle d’identité réel de la plateforme, et non d’un nom de fichier de lancement familier. Les vérifications ci-dessous partent de l’observation et remontent jusqu’à celui qui a réellement émis la demande.

Dans ces tickets, deux choses vont généralement mal ensemble : le mauvais composant est exclu, et l’exclusion n’est ensuite jamais resserrée.

Trouvez le processus, pas la fenêtre

Reproduisez l’opération qui échoue et identifiez le processus ou le paquet qui possède la connexion pendant qu’elle se produit. Sous Windows, c’est une autre question que celle de la fenêtre qui a le focus, car un transfert en arrière-plan peut être intermédié par un service qui s’exécute sous sa propre identité. Sous Linux et macOS, la même séparation apparaît sous forme de processus auxiliaires et de démons système.

Notez trois détails : l’identité de l’exécutable ou du paquet, la destination contactée et le moment du flux de travail où cela s’est produit. Un téléchargement qui échoue au début est souvent une récupération de métadonnées par un autre composant qu’un téléchargement qui échoue à mi-parcours. Cette seule distinction suffit généralement à choisir la bonne identité avant de toucher à la règle. Si l’identité s’avère être un service plutôt qu’une application, ce seul fait change toute la règle, alors établissez-le d’abord.

Si vous ne pouvez pas observer le processus parce que l’opération est trop brève, répétez-la avec une charge plus grande ou une destination plus lente. Le but est une observation reproductible, pas une théorie sur l’auxiliaire impliqué.

Traitez le DNS comme un chemin à part

La résolution de noms du système peut ne pas suivre du tout l’application exclue, ce qui explique qu’un navigateur exclu puisse encore échouer sur un nom d’hôte privé alors que son trafic est correctement hors du tunnel. Le navigateur était exclu ; le résolveur ne l’était pas.

Vérifiez ce que la plateforme fait du DNS lorsqu’une règle par application s’applique, et vérifiez-le séparément de la requête HTTP. Si le résolveur est un service partagé, il sert toutes les applications de l’appareil, donc l’exclusion que vous envisagez touche un public bien plus large que celle que vous avez testée.

Notez quel résolveur a répondu et par quelle interface. Cette seule observation résout une bonne part des rapports « l’application est exclue mais le nom ne se résout pas », alors conservez-la avec le ticket.

N’élargissez pas un auxiliaire partagé

Un service partagé effectue du travail pour plusieurs applications, donc l’exclure pour réparer un flux de travail modifie aussi du trafic sans rapport. Le Background Intelligent Transfer Service sous Windows est un bon exemple de cette forme : c’est une infrastructure que beaucoup d’applications peuvent utiliser, et son identité n’est pas celle de l’application qui a demandé le transfert.

Vérifiez le modèle de règles pris en charge par le client et les exigences de l’organisation avant d’ajouter cette exception. Demandez ce qui d’autre utilise le composant, et si la règle que vous êtes sur le point d’écrire peut s’exprimer par rapport à des destinations plutôt que par rapport à un processus partagé.

Si l’exigence ne peut pas du tout s’exprimer comme une frontière d’application, une politique fondée sur les destinations ou une autre conception approuvée peut être plus compréhensible et plus sûre qu’une liste croissante d’exceptions d’auxiliaires.

Testez tout le flux de travail, pas l’étape qui échoue

Après une modification prise en charge, exécutez la tâche prévue avec une nouvelle demande du début à la fin. Exécutez ensuite un autre flux de travail qui utilise le composant partagé, car c’est là qu’un contournement large se manifeste. Un correctif qui répare le premier et casse silencieusement le second n’est pas un correctif. Conservez les deux résultats dans le ticket et nommez explicitement le second flux de travail, pour qu’un relecteur puisse le répéter.

Gardez le test petit et reproductible : même destination, même compte, mêmes conditions. Si le second flux de travail n’est pas documenté, demandez à son propriétaire de quoi il dépend avant de décider que le changement est sûr.

Laissez une raison, pas une liste de noms

Documentez le composant, le flux de travail qu’il sert et la raison de son exclusion. Une liste de noms d’auxiliaires sans but associé devient ingérable en deux cycles de publication, et l’ingénieur suivant supprime la mauvaise entrée en la nettoyant.

Une ligne par exception suffit : ce qui casse sans elle, qui possède ce flux de travail et quand elle a été vérifiée pour la dernière fois. Ces trois champs transforment une liste mystérieuse en une politique que quelqu’un peut défendre.