Pourquoi Little Snitch liste-t-il encore le navigateur sous un VPN ?

Vous activez le VPN, ouvrez Little Snitch, et le navigateur est là, avec une connexion vers un site que vous croyiez passer par le tunnel. Cette entrée n’est pas en soi la preuve d’une fuite. Un moniteur local indique quel processus a ouvert une socket sur cette machine, et le navigateur l’a bien ouverte ; le client VPN est un second processus qui reprend ces paquets ensuite. Les deux affirmations sont vraies en même temps, et l’affichage vous montre la première.

Ce qu’un moniteur local peut attribuer et ce qu’il ne peut pas

L’attribution se fait au niveau de la socket. Le noyau sait quel processus possède une connexion, donc Little Snitch peut étiqueter une entrée avec le nom de l’application avec une grande confiance. Ce qu’il ne voit pas par défaut, c’est la connexion extérieure que le VPN construit autour de ce trafic, car elle appartient à un autre processus.

Les noms de domaine sont un signal plus faible qu’ils n’en ont l’air. Pour une connexion HTTPS, le nom peut venir d’une requête DNS, du nom de serveur proposé pendant la poignée de main ou d’une recherche inverse de l’adresse, selon ce que le système a observé. Rien de tout cela n’exige de déchiffrer la page, et rien ne prouve où les octets sont allés ensuite.

L’entrée du navigateur répond donc à qui, pas à où. Traitez-la comme une donnée d’attribution et obtenez le où depuis une autre vue.

Première étape : partir d’une fenêtre vide plutôt que de faire défiler l’historique

Les anciennes entrées ne peuvent pas vous dire ce que fait la configuration actuelle. Passez le filtre temporel sur À partir de maintenant, ou appuyez sur Command-K, pour que la fenêtre n’affiche que les connexions apparues après cet instant.

Faites ensuite exactement une chose inoffensive dans l’application que vous examinez, comme charger une page que vous êtes autorisé à charger. Une action, un instant, pour que les entrées qui apparaissent puissent y être rattachées sans deviner. Attendez une seconde ou deux après la fin, car un chargement de page produit une rafale de connexions et non une seule. Lire la liste pendant qu’elle se remplit encore garantit que vous jugerez mal l’ordre.

Avant de lire le résultat, vérifiez si un champ de recherche ou un filtre d’état restreint la liste. Un filtre laissé d’une session précédente est la raison la plus fréquente pour qu’une connexion semble manquer alors qu’elle est seulement masquée, et c’est aussi pourquoi deux personnes regardant la même machine ne sont pas d’accord sur ce qui se passe.

Deuxième étape : inclure les connexions des extensions pour voir le tunnel lui-même

Le client VPN sur une version actuelle de macOS est généralement une extension réseau plutôt qu’une application ordinaire. Activez Afficher les extensions réseau dans le Monitor et les connexions que fait cette extension deviennent visibles à côté de tout le reste.

Les deux couches peuvent maintenant se lire ensemble. Le navigateur est l’origine de la requête, et l’extension est le transport qui la porte. Voir les deux est normal et attendu ; ne voir que l’extension signifie généralement que la vue est filtrée, tandis que ne voir que l’application signifie généralement que la vue des extensions est désactivée.

Aucune vue à elle seule n’inventorie tout le chemin. Les règles de routage, le comportement du DNS et d’éventuelles exceptions par application vivent hors de la liste des connexions, donc une réponse complète exige de les vérifier séparément.

Troisième étape : distinguer une vraie connexion directe d’un effet d’affichage

Si vous soupçonnez qu’une destination précise sort directement, nommez cette destination et vérifiez-la pour elle-même. Regardez la configuration de routage et de blocage du client VPN pour cet hôte ou cette application, et confirmez si elle est censée être exclue.

Ce que vous ne devriez pas faire, c’est bloquer en réaction chaque entrée visible du navigateur. Le navigateur doit de toute façon établir ses connexions, et les bloquer dans le moniteur ne les redirige pas vers le tunnel ; cela les arrête seulement. Cela transforme une question de diagnostic en panne. Si une règle semble nécessaire, limitez-la à l’unique destination que vous pouvez justifier, avec une note expliquant pourquoi elle existe.

La même prudence vaut pour la colonne des domaines. Un nom qui vous surprend peut être un nom d’hôte partagé, un point de livraison de contenu ou une résolution survenue avant que le tunnel monte, et le traiter comme une preuve de fuite mène à des règles qui cassent du trafic qui fonctionne.

Quatrième étape : garder la vue et la règle séparées

Chaque changement dans cet exercice modifie ce que le moniteur affiche. Aucun ne modifie ce que le pare-feu autorise, et aucun ne déplace du trafic vers le tunnel ou hors de lui.

Quand vous avez terminé, remettez les filtres dans un état que vous pouvez expliquer, afin que la personne suivante qui ouvre la fenêtre ne lise pas une vue que vous avez laissée derrière vous. Si la question était de savoir si une destination passe par le tunnel, répondez-y à partir des réglages de routage et d’exclusion, puis servez-vous du moniteur pour confirmer le résultat plutôt que pour le deviner.