Tor sur VPN : qui voit votre IP et qui voit votre usage de Tor ?

Vous connectez le client VPN, attendez le tunnel, puis ouvrez Tor Browser et le laissez construire un circuit. Cette séquence banale décide qui voit quoi. Dans cet ordre, le relais d’entrée de Tor salue l’adresse de sortie de votre VPN, et votre fournisseur VPN salue un relais de garde public. Faites l’inverse et les deux observateurs changent. Les deux ordres méritent d’être parcourus, car les réglages du client cassent en silence la séquence que les gens croyaient en place, et la vérification qui le détecte est la même dans les deux cas.

Commencez par l’ordre, pas par le produit

Deux dispositions s’appellent « VPN avec Tor », et seule la première est courante. Avec Tor sur VPN, le tunnel est déjà monté quand Tor démarre, donc le processus tor envoie sa connexion de garde dans le tunnel comme n’importe quel trafic sortant. Avec VPN sur Tor, Tor démarre en premier et la session VPN elle-même traverse le circuit, arrivant chez le fournisseur depuis une sortie Tor.

Ce qui change entre elles, c’est quelle adresse se trouve à l’extrémité du maillon le plus extérieur. Chaque observateur ne voit que le saut précédent, jamais le chemin entier : la garde voit qui s’est connecté à elle, et le serveur VPN voit qui s’est connecté à lui. Tor ne transporte pas votre adresse de tunnel locale vers l’extérieur, et il n’existe aucun champ dans le protocole où il pourrait le faire.

Dans les deux ordres, le site de destination voit toujours une sortie Tor, et aucun ordre ne change ce que ce site apprend de votre connexion. La différence se limite aux deux bords.

Ce que voit le relais d’entrée de Tor

L’entrée, ou garde, accepte une connexion TCP ordinaire sur un port de relais et entame une poignée de main TLS avec le client. Dans une configuration Tor sur VPN, la source de cette connexion est votre sortie VPN. Dans une configuration Tor d’abord, c’est l’adresse que votre machine a utilisée pour atteindre le réseau Tor, normalement votre connexion domestique.

Cela répond à la moitié IP de la question, mais seulement si le tunnel a réellement transporté la connexion. Le processus Tor atteint la garde avec sa propre socket, et cette socket n’est pas régie par les réglages de proxy de Tor Browser. Le navigateur parle au processus tor embarqué via SOCKS sur le 9150, puis tor ouvre sa propre connexion à l’aide de la table de routage du noyau. Une ligne Socks5Proxy dans torrc, ou un transport client, change ce chemin. Rien d’autre ne le fait.

Sous Linux, vous pouvez lire la réponse sur la machine. Demandez au noyau quelle interface il utiliserait pour une adresse publique quelconque, puis regardez l’adresse locale de la connexion établie :

ip route get 203.0.113.10
sudo ss -tnp | grep -i tor

Si la route indique dev wg0 ou dev tun0, et que l’adresse locale de la connexion établie est l’adresse du tunnel, Tor est à l’intérieur du VPN. Si la route nomme votre interface physique, il est à l’extérieur, quoi qu’affirme l’indicateur du client.

Ce que votre fournisseur VPN peut voir

Le fournisseur termine votre session VPN, il voit donc les adresses auxquelles vous vous connectez. Les adresses des relais de garde sont publiées dans le consensus public et leurs ports sont bien connus, donc en apparier une est une recherche dans une liste, pas une inspection approfondie des paquets. Un fournisseur n’a pas besoin de casser Tor pour savoir qu’une session est Tor.

Ce qu’il ne voit pas, c’est le reste du circuit. Le relais intermédiaire et la sortie sont choisis à l’intérieur de Tor, et le fournisseur ne gère que le maillon vers la garde. Le contenu de la page reste dans le TLS qui se termine à la sortie, et la résolution de noms pour le trafic Tor se fait aussi à la sortie, donc il n’y a aucune requête DNS chez le fournisseur à corréler avec une destination.

Les ponts avec obfs4 changent la recherche, pas la topologie. L’adresse d’un pont est absente de la liste publique des relais et le trafic est façonné pour ne pas ressembler à Tor, donc un opérateur qui ne compare que des adresses ne le signalera pas. La session vient toujours de votre client VPN, et le fournisseur voit toujours un point de sortie, un volume et un emploi du temps.

La capacité n’est pas une politique de conservation

Un opérateur qui peut observer une connexion n’a pas promis de la conserver. La journalisation est une décision distincte, écrite dans une politique, limitée par la juridiction et vérifiable seulement par des preuves auxquelles vous faites déjà confiance. Une étiquette sans journaux ne change pas le rôle réseau décrit plus haut.

L’identité du compte compte généralement plus que l’adresse de sortie. Si vous vous êtes connecté avec une adresse e-mail, ou si vous avez payé par carte, le fournisseur peut rattacher la session à vous sans journaliser une seule destination. Faire tourner les IP de sortie n’y change rien.

Vérifiez la couverture avant de faire confiance à l’une ou l’autre réponse

La plupart de ceux qui croient faire tourner Tor sur VPN n’en font tourner qu’une partie. Le tunneling divisé qui exclut Tor Browser, un coupe-circuit qui couvre le navigateur mais pas le service tor, une unité de démarrage qui s’exécute avant que le tunnel soit monté, et un chemin IPv6 qui contourne le tunnel sont les quatre habituels.

Lire l’écran d’état du client n’en teste aucun. Le test qui le fait : laissez Tor Browser tourner, coupez le tunnel et regardez si la connexion de garde survit sur l’interface physique.

L’ordre dans lequel je vérifie, en m’arrêtant au premier échec :

• ip route get 203.0.113.10 renvoie le périphérique du tunnel.
• ss -tnp | grep -i tor montre la connexion de garde avec une adresse locale de tunnel.
• ip -6 route n’a pas de route par défaut hors du tunnel, ou l’IPv6 est désactivé dans le client.
• Couper le VPN termine ou redirige la connexion tor au lieu de la laisser sur le lien physique.

Quel ordre correspond à ce que vous défendez

Les deux ordres cachent quelque chose et en exposent une autre, donc la réponse est un choix sur l’observateur qui vous importe.

Lisez-le par colonne jusqu’à ce qu’une ligne corresponde à ce que vous cherchez à empêcher. Si l’inquiétude est un réseau local ou un fournisseur d’accès qui enregistre ou bloque Tor, Tor sur VPN s’en charge. Si l’inquiétude est que l’opérateur VPN apprenne votre adresse de domicile, VPN sur Tor s’en charge, et le paie en exposant l’usage de Tor à votre propre réseau et votre adresse de domicile à la garde.

Aucune des deux dispositions ne laisse les deux bords aveugles. Ajouter un observateur n’en retire pas un. La note du Tor Project sur l’exécution d’un VPN avec Tor dit la même chose dans l’autre sens : le tunnel change à qui l’on fait confiance et quels chemins de défaillance existent, donc ce n’est pas une amélioration à ajouter sans décider ce que vous vouliez cacher.

Décidez d’abord l’observateur, choisissez ensuite l’ordre, et vérifiez avec ip route get et ss plutôt qu’avec l’indicateur du client. Si l’observateur est quelqu’un qui peut contraindre le fournisseur VPN lui-même, aucun choix d’ordre n’y remédie.