Où va le DNS quand vous combinez Tor et un VPN

Deux outils de confidentialité tournent, une page ne se charge pas, et un test de résolution dit que quelque chose hors du navigateur a reçu un nom. Avant que cela ne devienne un rapport de fuite, nommez l’échange d’où il vient. Une configuration Tor plus VPN contient au moins trois recherches de noms différentes avec trois propriétaires différents, et les parcourir dans l’ordre où ils se produisent est le moyen le plus rapide de voir lequel se comporte mal.

Nommez chaque échange avant de parler de fuite

Le premier échange résout le point de terminaison du VPN lui-même, et il a lieu avant qu’une quelconque protection existe. Le second résout une destination pour le navigateur Tor, qui peut remettre le nom au proxy au lieu de le résoudre localement. Le troisième couvre tout le reste sur la machine, y compris les vérifications de mise à jour, les clients de messagerie et les requêtes de service du système d’exploitation lui-même. Seul le premier peut se produire sans que les deux autres soient impliqués.

Chacun d’eux peut suivre un chemin différent, et un seul test dans le navigateur n’observe que sa propre requête. Prendre un résultat pour l’état des trois, c’est là que commence l’essentiel de la confusion.

Notez quels noms appartiennent à quelle couche avant de changer quoi que ce soit. Les noms organisationnels privés, une destination publique et le point de terminaison du tunnel lui-même n’ont pas la même exigence, et une politique qui les traite comme une seule catégorie cassera quelque chose.

La requête d’amorçage a lieu avant le tunnel

Un client configuré avec un nom d’hôte doit résoudre ce nom pour ouvrir le tunnel, et à ce moment-là aucun tunnel n’existe pour porter la requête. Le résolveur que le système d’exploitation propose sur le réseau actuel répond, ce qui peut être un portail captif, un résolveur d’hôtel ou un résolveur public. Ce n’est pas une fuite dans le tunnel, car il n’y a pas encore de tunnel.

Changer le réglage de DNS sécurisé du navigateur ne touche pas non plus cette requête, car elle appartient à un service qui s’exécute hors du navigateur et démarre avant l’ouverture de la moindre page. Si le nom du point de terminaison ne se résout pas, aucune politique à l’intérieur du tunnel n’aidera, car l’échec se produit une étape avant tout ce que la configuration décrit.

C’est le seul endroit où l’utilisation d’une adresse littérale pour le point de terminaison, si le fournisseur la prend en charge, retire une dépendance au lieu d’en ajouter une. Elle retire aussi la possibilité de suivre un fournisseur qui fait tourner les adresses, donc le compromis est réel et devrait être décidé plutôt que découvert.

Le navigateur et le reste de la machine diffèrent

L’interface SOCKS de Tor permet de transmettre un nom d’hôte de destination au proxy, ce qui signifie que l’extrémité distante effectue la résolution et que la machine locale ne demande jamais. Une application générique qui prend en charge un proxy peut d’abord résoudre le nom localement puis se connecter à l’adresse obtenue, ce qui produit une requête locale pour une destination que l’utilisateur croyait proxifiée. Les deux applications peuvent donc fuir à des endroits différents tout en partageant un unique réglage de proxy. Rien dans une adresse de proxy partagée ne vous dit lequel des deux comportements est utilisé.

Les navigateurs ajoutent une autre couche lorsque le DNS sécurisé est activé, car le navigateur peut choisir son propre fournisseur et contourner entièrement le résolveur du système. Le client du tunnel, lui, peut pousser un résolveur à travers le tunnel pour toute la machine. Ces deux réglages peuvent être corrects tous les deux et décrire malgré tout des comportements différents pour des programmes différents.

Vérifiez le programme qui a fait la requête au lieu d’extrapoler à partir d’une page de test. La distinction entre une requête portée à l’intérieur du tunnel et une qui n’a jamais atteint Tor est exactement la distinction qu’une seule adresse de résolveur ne peut pas montrer.

Vérifiez chaque programme, puis comparez avec l’intention

Faites les observations séparément : ce que le système utiliserait, ce pour quoi le navigateur est configuré, et si la connexion SOCKS porte un nom ou une adresse. Ce dernier point est la différence entre résolution distante et locale, et spécification des extensions SOCKS décrit comment un nom d’hôte est transmis au lieu d’être d’abord résolu.

resolvectl status | grep -E "Current DNS Server|DNS Servers"
ss -tnp '( dport = :9050 )'
dig +short dev.internal.example
getent hosts vpn-endpoint.example.net

Comparez ensuite ce que vous avez observé avec ce que vous vouliez. Un nom public résolu à travers le tunnel par un résolveur que vous avez choisi n’est pas la même constatation qu’un nom privé remis à un résolveur public lors d’un repli, et seul le second demande généralement une action. Le premier est une configuration qui fonctionne comme prévu, même s’il paraît inhabituel dans un rapport.

Consignez les exceptions que vous acceptez, y compris la requête d’amorçage qui ne peut pas être protégée. Une exception écrite est une décision de conception, tandis que la même exception découverte plus tard ressemble à un défaut. Celui qui la trouvera la traitera comme tel, et vous passerez la réunion à expliquer pourquoi ce n’est pas le cas.