Relais de sortie Tor contre serveur de sortie VPN : ce que chacun sait

Les deux conceptions cachent votre adresse derrière une seule IP publique, et un site qui imprime l'adresse qu'il voit ne peut pas les distinguer. La différence tient à qui apprend quoi en chemin, à la quantité de trafic couverte et aux ports autorisés à fonctionner. Un relais de sortie Tor est le dernier saut d'un circuit de trois relais ; un serveur de sortie VPN termine votre tunnel et établit lui-même la connexion sortante. Voici comment je décide lequel une tâche exige, et ce que je vérifie avant de supposer que l'un se comporte comme l'autre.

Deux chemins qui aboutissent à une adresse

Tor construit un circuit via un garde, un relais intermédiaire et une sortie, et chiffre la charge en couches pour que chaque relais n'en retire que la sienne. La sortie établit la connexion TCP ordinaire vers la destination, d'où le fait que la destination voie l'adresse de sortie. Votre client ne parle jamais directement à la destination, et le garde ne la voit pas non plus.

Un VPN est un tunnel vers un point de terminaison. Le serveur de l'opérateur retire le tunnel et ouvre la connexion sortante, si bien que la destination voit aussi une seule adresse, cette fois celle de l'opérateur. Le résultat observable est le même ; le savoir ne l'est pas. Un test qui imprime une IP répond sur quel système vous êtes et rien sur le partage de confiance qui diffère réellement.

Qui finit par savoir quoi

Le point de terminaison VPN voit l'adresse source, la destination, le moment et le volume au même endroit. Cette concentration est la conception : un opérateur, une surface de journaux, un lieu à assigner ou à mal configurer. Tout ce que vous gagnez vient de la confiance en cette partie et de la politique de sortie du point de terminaison.

Tor répartit ce savoir. Le garde connaît votre adresse mais pas la destination ; la sortie connaît la destination mais pas votre adresse. Un relais n'est pas censé apprendre les deux. C'est une propriété structurelle, non une promesse contre un observateur mondial, un relais qui corrèle les horaires ou un point de terminaison compromis, alors traitez-la comme une autre répartition du même risque et non comme un anonymat qui ne peut pas échouer.

La couverture est une décision du navigateur ou de la route

Le navigateur Tor route son propre trafic et ajoute des protections qu'un client VPN générique ne reproduit pas : résistance aux empreintes, isolation de première partie, une taille de fenêtre fixe et une action Nouvelle identité qui jette l'état de session. Les autres applications n'utilisent pas ce circuit sauf si elles sont configurées pour cela, et une installation Tor à l'échelle du système est un projet distinct de l'installation du navigateur.

Un VPN a la forme inverse. La couverture suit la table de routage, si bien qu'un profil WireGuard avec AllowedIPs = 0.0.0.0/0 capture tout et qu'une liste de tunnel divisé ne capture que les préfixes qu'elle nomme. C'est précisément dans ce mécanisme que vivent aussi les fuites : les requêtes DNS, IPv6 et WebRTC peuvent chacune emprunter un chemin que la politique de routage n'incluait pas. Vérifiez depuis l'application qui a échoué, pas depuis un onglet de navigateur qui utilise peut-être une autre interface.

Politique de ports, destinations bloquées et HTTPS

Un relais de sortie est libre de refuser des ports sortants, et la politique par défaut rejette une liste de ports propices aux abus, dont le port SMTP 25. Un client de messagerie configuré via Tor échoue donc à la sortie, ce qui ressemble à une panne réseau sans en être une. Les opérateurs qui tiennent un relais l'indiquent explicitement :

# torrc — refuse outbound SMTP from this relay
ExitPolicy reject *:25

Les destinations bloquent aussi, et elles bloquent les deux systèmes différemment. Les adresses de sortie Tor sont publiées, si bien qu'un site peut refuser toute la liste ; les points de terminaison VPN se trouvent dans des plages de centres de données refusées tout aussi négligemment. Quand une page échoue, séparez les trois candidats avant de changer quoi que ce soit : politique de sortie ou d'égression, destination refusant la source, ou portail captif qui détourne la première requête.

Aucun des deux systèmes ne remplace le chiffrement de transport. Le HTTP simple est lisible au relais de sortie comme au point de terminaison VPN, alors laissez HTTPS activé et lisez l'avertissement de certificat au lieu de l'écarter. Deux contrôles règlent vite la question du routage : curl -s https://check.torproject.org/api/ip renvoie IsTor quand la requête est passée par un circuit, et curl -s https://ifconfig.me affiche l'adresse de sortie qu'un VPN présenterait. Exécuter les deux vous dit quel chemin l'interpréteur de commandes utilise réellement.

N'utilisez pas l'un comme l'autre

L'adresse d'un relais de sortie n'est pas un profil VPN. Pointer un client OpenVPN ou WireGuard vers un relais sur le port 443 ne crée pas de tunnel, car aucun service VPN n'y écoute ; le relais est un saut dans le circuit de quelqu'un d'autre. Dans l'autre sens, un point de terminaison VPN n'est pas un point d'entrée pour Tor, et les réglages de ponts du navigateur Tor ne sont pas un endroit où coller un nom d'hôte de VPN commercial. Si vous faites tourner Tor sur un VPN, le garde voit l'adresse du VPN au lieu de la vôtre, ce qui change la répartition sans fusionner les deux rôles.

Avant de choisir, répondez à quatre questions dans l'ordre : qui exploite le point de terminaison et que conserve-t-il, que couvre l'outil sur cet appareil, quels ports et destinations la politique de sortie autorise-t-elle, et qu'ajoute l'application au-delà du chemin réseau. Une tâche qui a besoin d'un accès réseau ordinaire pour de nombreux programmes veut un VPN. Une tâche qui a besoin des protections au niveau du navigateur et du modèle de circuit veut le navigateur Tor, tenu à jour. Si la réponse est « les deux », exécutez-les dans un ordre délibéré et notez quelle adresse chaque côté voit.