VPN via Tor : d’abord la vérification du transport
Tor transporte TCP, pas UDP. Passez en revue le transport, les positions d’observateur et les couches de défaillance avant de traiter un VPN via Tor comme une navigation anonyme.
Tor d’abord signifie que le client VPN se trouve derrière un proxy SOCKS, donc le tunnel lui-même est construit via Tor et le trafic des applications sort par le point de sortie du VPN. C’est un ordre précis, et ce n’est pas ce que la plupart des gens construisent. Ouvrir Tor Browser à côté d’un client VPN ordinaire ne force aucun des deux programmes à utiliser le chemin de l’autre.
Passez les vérifications dans l’ordre. Chacune décide si la suivante vaut la peine d’être commencée.
Quel ordre construisez-vous réellement
Deux ordres se confondent dans la même conversation. Tor d’abord signifie que le client VPN atteint son serveur via un proxy SOCKS, donc le tunnel est construit par-dessus Tor. VPN d’abord signifie que le trafic de Tor sort par le tunnel, ce que la plupart des gens construisent par accident puis décrivent comme l’autre. Le premier concentre la frontière de transfert chez l’opérateur du VPN, le second la concentre à l’entrée et à la sortie de Tor. Aucun des deux n’est ce que vous obtenez en gardant les deux applications ouvertes en même temps.
Notez quel ordre la tâche exige avant de configurer quoi que ce soit, car les deux demandent des réglages logiciels différents et échouent à des endroits différents. Un ordre mal étiqueté vous envoie déboguer la mauvaise couche pendant une heure. Tout ce qui suit suppose Tor d’abord.
Vérifiez le transport avant tout le reste
L’interface SOCKS de Tor transporte des flux TCP et ne fournit pas d’association UDP générale. Un VPN dont le transport est UDP ne peut pas traiter ce proxy comme une interface réseau ordinaire, et aucun réglage client ne change ce que le proxy accepte de transmettre. WireGuard dans sa forme habituelle est la victime évidente. Un profil OpenVPN en mode TCP est la solution courante, et il faut encore lui dire explicitement d’utiliser le proxy.
ss -lntp | grep 9050
curl --socks5-hostname 127.0.0.1:9050 -o /dev/null -w '%{http_code}\n' https://example.com
Confirmez que le proxy écoute et peut transporter une simple requête HTTPS avant de déboguer un tunnel à travers lui. Si la requête simple échoue, le client VPN ne réussira jamais et ses journaux ne vous diront pas pourquoi.
Réécrivez la carte de l’observateur
L’entrée de Tor peut voir la source qui se connecte à Tor à moins que quelque chose d’antérieur ne l’ait changée, donc ce saut apprend votre adresse. Le fournisseur du VPN reçoit une connexion venant du côté de Tor mais peut encore connaître un compte, un enregistrement de paiement ou un identifiant que vous avez envoyé dans le tunnel. Les destinations atteintes via le VPN voient sa sortie plutôt que la sortie de Tor, et cela concentre la frontière finale de transfert chez un seul opérateur.
Il ne recrée pas non plus un chemin distribué vers chaque destination. Tor Browser construit un circuit neuf par site ; un VPN porté par Tor construit un seul tunnel, et chaque site derrière lui partage ce point de sortie. Traitez la différence comme un fait de conception et non comme une limite à lisser.
Comptez les couches de défaillance quand cela casse
Une configuration cassée comporte au moins quatre couches indépendantes : la connexion SOCKS, la poignée de main TLS avec le serveur VPN, la poignée de main du VPN elle-même, puis le routage ou la résolution de noms à l’intérieur du tunnel. Chacune échoue avec un symptôme différent et chacune nécessite une réparation différente. Assouplir les contrôles de certificat parce que le tunnel ne monte pas est le diagnostic erroné classique, et cela transforme un problème de transport en problème de sécurité.
Consignez la première couche qui échoue et arrêtez-vous là. Un refus du proxy et une clé rejetée ne sont pas des variantes du même événement.
Arrêtez-vous si le modèle de menace exige les défenses de Tor Browser
Router des applications arbitraires via un VPN porté par Tor ne donne pas à ces applications les fonctions d’empreinte et d’isolation de Tor Browser. Leurs comptes, identifiants et leur propre comportement réseau restent pertinents, et un tunnel n’en normalise aucun. Si l’objectif est un navigateur qui se fond parmi les autres utilisateurs, cet ordre ne le fournit pas.
Le Tor Project lui-même met en garde contre des combinaisons que les utilisateurs ne peuvent pas configurer correctement, et celle-ci vaut pour la plupart des gens. C’est une conception délibérée pour un modèle de menace étroit, pas un raccourci vers un trafic anonyme sur tout l’appareil.