Ce que votre fournisseur voit encore lorsque vous téléchargez en torrent via un VPN

Parcourez les questions dans l’ordre : ce que le réseau d’accès peut observer, ce qui quitte le tunnel sans lui, ce que la résolution de noms révèle, et ce que les pairs et les traqueurs apprennent malgré tout. Chaque réponse est indépendante des autres, et un VPN ne traite pleinement que la première. La quatrième est l’endroit où la plupart des attentes échouent en silence, car aucun tunnel ne supprime un nom de compte.

Commencez par décider quel observateur vous préoccupe, car la réponse change avec l’observateur.

Une connexion remplace beaucoup d’autres

Lorsque le client est réellement à l’intérieur du tunnel, le réseau d’accès voit une seule connexion chiffrée continue vers une unique adresse VPN. Le volume, le moment et le fait qu’un VPN est utilisé restent visibles ; les noms d’hôte des traqueurs, les adresses des pairs et les noms de fichiers non. C’est une amélioration réelle, et plus étroite que ne le suggère le marketing. L’opérateur du tunnel se trouve au milieu et voit plus que le réseau d’accès.

Une déclaration d’absence de journaux décrit une politique de conservation, non une visibilité technique. Ce sont des affirmations différentes, et seule la première est quelque chose qu’un fournisseur peut promettre.

La fuite vient de la liaison, pas du tunnel

BitTorrent crée un flux de connexions TCP et UDP de courte durée vers des pairs, des traqueurs, des nœuds DHT et la découverte locale. Liez le client à l’adaptateur physique, ou redémarrez-le une fois le tunnel tombé, et le trafic produit est exactement ce que le tunnel existait pour dissimuler. Les règles de pare-feu sont un contrôle plus faible qu’elles n’en ont l’air : une règle qui ne correspond qu’à la route par défaut, qu’à IPv4 ou qu’aux nouvelles connexions laisse des chemins ouverts. Lier le client à l’interface du tunnel et vérifier cette liaison est le schéma le plus solide.

Vérifiez en arrêtant volontairement le tunnel et en observant si les transferts s’arrêtent. S’ils continuent, le client n’était jamais à l’intérieur. Répétez après un redémarrage du client et après le réveil d’un ordinateur portable, car c’est là que les liaisons se perdent généralement.

Le DNS nomme le site sans toucher au transfert

Si les recherches de noms passent encore par le résolveur local, la requête elle-même annonce le site tandis que le transfert reste chiffré. Déplacer la résolution dans le tunnel, ou la chiffrer, comble cette lacune. Ni l’un ni l’autre ne fait rien pour un client dont les paquets sortent hors du tunnel. Vérifiez quel résolveur est utilisé et par quelle interface la requête sort ; les deux contrôles répondent à des questions différentes.

Un nom qui se résout à travers le tunnel et un transfert qui respecte la liaison sont des propriétés distinctes, et chacune peut échouer seule.

L’essaim et le traqueur voient des choses différentes

L’échange d’adresses fait partie du protocole, donc les pairs enregistrent ce qu’ils voient. Se connecter depuis la sortie leur donne la sortie ; se connecter directement leur donne l’adresse du domicile. DHT et l’échange de pairs propagent cette observation, et une session ultérieure sans le tunnel peut relier le même port client et la même version. Le traqueur peut en savoir plus encore : une clé d’accès dans l’URL d’annonce identifie le compte, quelle que soit la sortie d’où viennent les paquets.

Le chiffrement couvre encore un autre axe. HTTPS protège une requête depuis la sortie ; le HTTP simple expose la ligne de requête à chaque réseau du chemin, et c’est pourquoi un protocole peut être façonné et l’autre non.

Répondez aux quatre questions avec des preuves, pas avec une icône. L’icône vous dit seulement qu’un tunnel existe.